Microsoft Dynamics 365 Data Exposure: Fetching Your Way to Password Hashes 🔑

Critical Vulnerabilities in Dynamics 365 and Power Apps Web API Expose Sensitive Enterprise Data

In early 2024, cybersecurity researchers from Melbourne-based Stratus Security uncovered a trio of severe security vulnerabilities in Microsoft Dynamics 365 and Power Apps Web API that could have exposed millions of sensitive user records to unauthorized access. These critical flaws, which were discovered during routine penetration testing and subsequently patched by Microsoft as of May 2024, could potentially allow attackers to bypass access controls and retrieve password hashes, email addresses, financial data, phone numbers, and other personally identifiable information stored within the contacts table.

The vulnerabilities highlight a sobering reality for enterprise organizations: even sophisticated platforms with robust security frameworks can harbor critical weaknesses in their API implementations. This comprehensive analysis examines the three vulnerabilities discovered by Stratus Security, their exploitation mechanisms, real-world impact, and essential remediation strategies for protecting Dynamics 365 and Power Apps environments.

Understanding the Vulnerability Landscape

What is Microsoft Dynamics 365 and Power Apps?

Microsoft Dynamics 365 serves as Microsoft’s comprehensive CRM/ERP solution, while Power Apps are low-code/no-code platforms for building applications and websites used by businesses worldwide. When these applications communicate with Power Pages, data is stored in the “Dataverse” and can be optionally exposed via an API with fine-grained access controls. The vulnerabilities exploited weaknesses in precisely these access control mechanisms.

The Discovery Process

The vulnerabilities were initially discovered during web application penetration testing on an app hosted on Microsoft Power Pages, when the researcher decided to conduct additional investigation of the API functionality. This decision proved critical, ultimately revealing three distinct but related vulnerabilities that could compromise the security of any organization using these platforms.

Vulnerability #1: OData Web API Filter Access Control Flaw

Technical Overview

The first vulnerability stemmed from inadequate access controls on the OData Web API Filter, which permitted unauthorized access to sensitive data within the contacts table including full names, phone numbers, addresses, financial details, and password hashes. The Open Data Protocol (OData) is designed to provide standardized REST-based data access, but in this case, the access restrictions were insufficient.

Exploitation Mechanism: Boolean-Based Character Extraction

The exploitation technique employed a clever boolean-based search methodology that allowed attackers to extract complete password hashes character by character. Attackers could perform sequential searches starting with queries like startswith(adx_identity_passwordhash, ‘a’), then startswith(adx_identity_passwordhash, ‘aa’), then startswith(adx_identity_passwordhash, ‘ab’) and continuing this process until the complete hash value was obtained.

This blind boolean-based extraction method works by:

Initial Query: Starting with a single character guess
Result Validation: Checking if the query returns results
Iterative Refinement: Adding characters sequentially based on positive results
Complete Extraction: Continuing until no further valid characters are found

The beauty (from an attacker’s perspective) of this technique is its reliability and automation potential. A simple script could systematically extract entire password databases given sufficient time.

Real-World Impact

The ability to extract password hashes has severe implications:

Credential Compromise: Weak password hashes could be cracked using rainbow tables or brute-force methods
Lateral Movement: Compromised credentials enable attackers to access other systems
Identity Theft: Combined with personal information, stolen credentials facilitate identity fraud
Corporate Espionage: Competitive intelligence gathering through unauthorized data access

Vulnerability #2: OData Orderby Clause Exploitation

Technical Details

The second vulnerability was discovered while validating the patch for the first flaw, and it exploited the orderby clause in the OData Web API to obtain data from specific database table columns. This vulnerability proved even more dangerous than the first because it directly returned the data, making large-scale exploitation significantly easier.

Exploitation Vector

Unlike the first vulnerability that required iterative character-by-character extraction, the orderby clause vulnerability allowed attackers to:

Craft queries targeting specific columns (such as EMailAddress1 for primary email addresses)
Retrieve data in descending order to prioritize high-value targets
Extract complete records with minimal query overhead
Scale attacks across multiple tables and environments

The vulnerability was reported to Microsoft on February 13, 2024, confirmed on February 22, and was eligible for a $20,000 cross-tenant information disclosure bounty award due to its wide reach.

Data Exposure Scenarios

The orderby vulnerability enabled several attack scenarios:

Mass Email Harvesting: Extracting thousands of email addresses for phishing campaigns
Customer Database Theft: Downloading complete customer contact information
Competitive Intelligence: Accessing business contacts and relationships
Targeted Attacks: Identifying high-value individuals for spear-phishing

Vulnerability #3: FetchXML API Access Control Bypass

Understanding FetchXML API

FetchXML is an XML-based query language proprietary to Microsoft Dynamics 365 that provides powerful data retrieval capabilities. While flexible and robust, the implementation of FetchXML API contained a critical flaw that allowed complete access control bypass.

The Critical Flaw

When utilizing the FetchXML API, attackers could craft an orderby query on any column, completely bypassing existing access controls, and unlike previous vulnerabilities, this method did not require the orderby to be in descending order, adding flexibility to the attack.

This third vulnerability represented the most versatile of the three because:

Universal Column Access: Any column could be queried regardless of access restrictions
Flexible Ordering: No requirement for specific ordering constraints
Complete Bypass: Access controls were entirely circumvented
Ease of Exploitation: Required only basic understanding of FetchXML syntax

Attack Methodology

The FetchXML vulnerability functioned similarly to the previous orderby vulnerability, allowing attackers to access restricted columns using an orderby query, and a single exposed column was sufficient to exploit this vulnerability and gain unauthorized access to sensitive data.

The attack chain typically followed this pattern:

Reconnaissance: Identify a single exposed column in the target table
Query Construction: Build FetchXML query with orderby clause targeting restricted columns
Execution: Submit query through the FetchXML API endpoint
Data Extraction: Retrieve complete restricted column data
Lateral Expansion: Repeat across multiple tables and environments

The Disclosure and Remediation Timeline

Responsible Disclosure Process

The vulnerability disclosure process began on December 2, 2023, when Stratus Security provided Microsoft with a detailed writeup of the first vulnerability including a demonstration GIF showing password hash extraction and a Proof of Concept for testing.

The timeline unfolded as follows:

December 2, 2023: Initial vulnerability reported to Microsoft February 3, 2024: Microsoft confirmed patch deployment for first vulnerability February 4, 2024: Microsoft patched the initial vulnerability, causing the filter technique to return the same response as the select statement when referencing a disabled column February 13, 2024: Second vulnerability discovered during patch validation February 22, 2024: Second vulnerability confirmed by Microsoft Early March 2024: Second vulnerability patched March 22, 2024: Third vulnerability discovered and immediately reported May 2024: All three vulnerabilities fully remediated

Challenges in the Disclosure Process

Over the month and a half following initial disclosure, there was significant back and forth between the researchers and Microsoft, including a few misunderstandings. This highlights the complexity of vulnerability disclosure even with cooperative vendors.

Additionally, the cascade nature of these vulnerabilities—where fixing one revealed another—demonstrates how defense-in-depth principles apply not just to prevention but also to detection and remediation.

Organizational Impact and Risk Assessment

Potential Attack Scenarios

Organizations running vulnerable Dynamics 365 and Power Apps implementations faced multiple attack vectors:

Scenario 1: Credential Harvesting Campaign Attackers could compile lists of password hashes and emails, then crack the passwords or sell the data on dark web marketplaces.

Scenario 2: Targeted Phishing Operations With access to complete contact databases including email addresses, phone numbers, and organizational relationships, attackers could launch highly sophisticated spear-phishing campaigns.

Scenario 3: Corporate Espionage Competitive intelligence gathering through systematic extraction of customer databases, financial records, and business relationships.

Scenario 4: Ransomware Precursor Initial access through compromised credentials, followed by lateral movement and eventual deployment of ransomware payloads.

Industries at Risk

These vulnerabilities posed particular risks to organizations in:

Financial Services: Banking, insurance, and investment firms with extensive customer data
Healthcare: Hospitals and healthcare providers managing patient information
Retail: E-commerce platforms with customer payment information
Professional Services: Consulting firms, law firms, and accounting practices
Government: Public sector organizations managing citizen data

Technical Deep Dive: Understanding the Root Causes

Access Control Failures

All three vulnerabilities shared a common root cause: insufficient access control validation at the API layer. The vulnerabilities exposed every other column in a table as long as a single column was exposed, which is a very common configuration.

This architectural weakness meant that:

Column-level security was not properly enforced at the API boundary
Query filters and ordering clauses bypassed authorization checks
Access control decisions relied on implicit rather than explicit validation
Defense-in-depth principles were not adequately implemented

API Security Anti-Patterns

The vulnerabilities demonstrated several common API security anti-patterns:

Insufficient Input Validation: API queries were not properly sanitized or validated against security policies

Trust Boundary Violations: The API trusted client-side requests without server-side verification

Information Disclosure: Error messages and query responses leaked information about database schema

Privilege Escalation: Limited access to one column enabled access to all columns

Mitigation Strategies and Best Practices

Immediate Remediation Steps

Organizations using Microsoft Dynamics 365 and Power Apps should take these immediate actions:

1. Verify Patch Status Confirm that all environments have been updated to versions released after May 2024.

2. Review Access Control Configurations Implement strict access controls to limit unauthorized queries on sensitive tables such as the contacts table, and use role-based access control (RBAC) to ensure only authorized users and applications can access sensitive data.

3. Audit API Permissions Regularly audit API permissions to detect and remove excessive or outdated access rights.

4. Enable Monitoring Introduce rate-limiting and monitoring for API requests to detect and block enumeration attempts.

Long-Term Security Enhancements

Enhanced Password Security Implement hashing algorithms like bcrypt or Argon2 for password hashes to increase computational complexity, making brute-force attacks impractical.

Query Validation Apply query validation and filtering to prevent unauthorized access to sensitive columns, and use API gateways or middleware to inspect and block malicious queries before they reach backend systems.

Column-Level Security Enforce strict query validation to ensure that only authorized columns can be queried regardless of the use of orderby, and apply column-level security to restrict access to sensitive data fields such as password hashes and email addresses.

Activity Monitoring Monitor and log API activity to detect unusual patterns that could indicate exploitation attempts, and conduct regular penetration testing and vulnerability assessments to uncover and address potential weaknesses.

Broader Implications for Enterprise Security

The API Security Challenge

These vulnerabilities underscore the critical importance of API security in modern enterprise environments. As organizations increasingly expose data through APIs to enable integration and automation, the attack surface expands dramatically.

Key lessons include:

Defense in Depth: Multiple layers of security controls are essential
Explicit Validation: Never trust client inputs or assume proper access control
Regular Assessment: Continuous security testing reveals evolving threats
Rapid Response: Quick patch deployment minimizes exposure windows

The Supply Chain Security Dimension

Organizations don’t just need to secure their own implementations—they must also trust their vendors to maintain robust security practices. The discovery underscores a critical reminder that cybersecurity requires constant vigilance, especially for large companies that hold significant amounts of data.

Security Architecture Recommendations

Implementing Zero Trust Principles

Organizations should adopt Zero Trust architecture principles for Dynamics 365 and Power Apps:

Never Trust, Always Verify: Authenticate and authorize every request Least Privilege Access: Grant minimum necessary permissions Assume Breach: Design systems expecting compromise Verify Explicitly: Use multiple factors for authentication

API Security Framework

Implement comprehensive API security controls:

Authentication: Strong multi-factor authentication for all API access
Authorization: Granular, policy-based access controls
Encryption: TLS 1.3 for all data in transit
Logging: Comprehensive audit trails for all API operations
Rate Limiting: Prevent enumeration and brute-force attempts
Input Validation: Strict sanitization of all user inputs
Output Encoding: Prevent information disclosure through error messages

Organizational Response and Governance

Incident Response Planning

Organizations should develop incident response plans addressing API vulnerabilities:

Detection Phase - Monitor for unusual API query patterns - Alert on failed authorization attempts - Track data exfiltration indicators

Containment Phase - Temporarily disable vulnerable API endpoints - Block suspicious IP addresses - Isolate affected environments

Eradication Phase - Apply security patches immediately - Review and remediate access controls - Remove unauthorized access credentials

Recovery Phase - Restore services with enhanced security - Validate security control effectiveness - Communicate with affected stakeholders

Lessons Learned Phase - Document incident timeline and response - Identify process improvements - Update security policies and procedures

Compliance and Regulatory Considerations

These vulnerabilities have significant implications for regulatory compliance:

GDPR: Data breach notification requirements if personal data was exposed HIPAA: Potential violations if protected health information was compromised PCI DSS: Payment card data exposure requires immediate response SOX: Financial data integrity concerns for public companies

Future Outlook and Evolving Threats

Emerging Attack Vectors

As APIs become increasingly central to enterprise architecture, attack vectors continue to evolve:

GraphQL Exploits: Emerging query language vulnerabilities
Microservices Attacks: Exploiting service-to-service communications
Serverless Vulnerabilities: Function-as-a-Service security gaps
AI/ML API Abuse: Exploiting machine learning model endpoints

Proactive Security Measures

Organizations should invest in:

API Security Testing: Regular automated and manual security assessments Threat Intelligence: Monitor emerging API vulnerability disclosures Security Training: Educate developers on secure API design patterns Continuous Monitoring: Real-time detection of API abuse and anomalies

Conclusion: Lessons Learned and Path Forward

The discovery of these three vulnerabilities in Microsoft Dynamics 365 and Power Apps Web API serves as a stark reminder that even mature, enterprise-grade platforms can harbor critical security flaws. The sophisticated exploitation techniques—from boolean-based character extraction to FetchXML orderby bypass—demonstrate the creativity and persistence of modern threat actors.

For organizations, the key takeaways are clear:

Assume Vulnerability: No system is perfect; plan for compromise
Layer Defenses: Multiple security controls provide resilience
Monitor Continuously: Early detection minimizes impact
Patch Rapidly: Quick remediation closes exposure windows
Test Regularly: Proactive security assessments reveal weaknesses

Microsoft’s response to these vulnerabilities—working with security researchers through responsible disclosure and deploying patches within months—demonstrates the importance of vendor cooperation in protecting the ecosystem. However, organizations cannot rely solely on vendors; they must take ownership of their security posture.

As enterprise applications increasingly depend on APIs for integration and automation, API security must become a top priority. The FetchXML API vulnerabilities remind us that powerful features can introduce powerful risks when not properly secured.

Organizations using Microsoft Dynamics 365 and Power Apps should immediately verify their patch status, review access controls, implement enhanced monitoring, and conduct security assessments to ensure they’re protected against these and similar vulnerabilities. The cost of prevention is always lower than the cost of breach response, remediation, and reputation damage.

In the constantly evolving landscape of cybersecurity threats, vigilance, proactive defense, and rapid response remain the cornerstones of effective security management. These vulnerabilities may have been patched, but the lessons they teach about API security, access control, and defense-in-depth architecture will remain relevant for years to come.

Keywords: Microsoft Dynamics 365 vulnerabilities, FetchXML API security, Power Apps Web API exploitation, password hash extraction, OData security flaws, Dataverse access control, enterprise API security, cybersecurity vulnerabilities 2024, CRM security risks, Microsoft security patches