Scope - What This Guide Covers
This guide focuses on preventing unauthorized data access through Microsoft Power Pages portals. It's tailored for security teams managing D365 CRM and ERP instances where Power Pages provides external access to business data.
The guide examines the vulnerability that led to ExfilSquad's data extortion campaign, resulting in 382.64 GB and 27 million records leaked from 13 organizations. Misconfigured table permissions allowed public read access, highlighting risks applicable to any SaaS platform where configuration errors can expose sensitive data.
You'll find requirement breakdowns, implementation steps, and a reference table for configuration reviews and security assessments.
Key Concepts and Definitions
Microsoft Power Pages: A platform for creating external-facing business websites that interact with Microsoft Dataverse tables containing CRM and ERP data.
Table Permissions: Access control settings that determine which web roles can perform create, read, update, or delete operations on specific Dataverse tables.
Anonymous Users Web Role: A default role in Power Pages that allows anyone visiting the site to access data without authentication when assigned to table permissions.
API Access Point: Power Pages exposes data through https://<portal>/_api/* endpoints, which can be queried directly if table permissions aren't properly restricted.
Misconfiguration Window: The period between portal deployment and proper security hardening when default settings may expose data to public access.
Requirements Breakdown
Configuration Requirements
Avoid Anonymous Users Role: Never assign the Anonymous Users web role to table permissions on publicly exposed sites. Microsoft advises against this.
Implement Authentication: Require authentication for all tables containing sensitive personal data, PII, financial records, or proprietary business information.
Apply Least Privilege: Assign web roles only the minimum data access necessary for their function.
Document Exposed Tables: Justify any table exposed through Power Pages, including data classification and approved access scope.
Monitoring Requirements
Log API Calls: Record all API calls to Power Pages endpoints, including IP address, timestamp, web role used, and tables accessed.
Alert on Anomalies: Establish baseline access patterns and alert on anomalies like bulk data exports or access from unexpected locations.
Quarterly Permissions Review: Regularly review table permissions across all Power Pages instances to identify configuration drift.
Implementation Guidance
Initial Deployment Controls
Treat new Power Pages portal deployments as high-risk changes requiring security review before production release. Your checklist should include:
- Inventory Tables: Classify the sensitivity of data in each table accessed by the portal.
- Map Access Patterns: Define required access patterns for each legitimate user type.
- Configure Permissions: Set table permissions to match access patterns, starting from a deny-all baseline.
- Test with Authenticated Roles: Ensure roles are tested before considering any public access.
- Verify API Endpoints: Ensure API endpoints return only expected data when queried without authentication.
The Fortra research team found over 10,000 potential Power Pages instances accessible to the public, indicating many organizations deploy these portals without adequate security review.
Automated Discovery and Hardening
Attackers use automated scanning to find misconfigured portals. You should do the same defensively:
- Enumerate Instances: Identify all Power Pages instances across business units. Shadow IT deployments are common with low-code platforms.
- Query API Endpoints: Test each portal's API endpoint from an unauthenticated session to identify exposed tables.
- Compare Exposures: Check discovered exposures against documented access requirements.
- Remediate Exposures: Immediately fix any table returning data that shouldn't be publicly accessible.
Run this discovery process monthly. ExfilSquad likely used similar scanning to identify victims, so you're in a race to fix misconfigurations before attackers do.
Monitoring for Unauthorized Access
Even with proper configuration, detection capabilities are essential if an attacker gains access through credential compromise or a zero-day vulnerability.
Your Security Information and Event Management system should alert on:
- Bulk Data Exports: Exceeding normal thresholds for the portal's business function.
- Sequential Table Enumeration: Suggesting reconnaissance activity.
- Access from Anonymizing Services: Or IP addresses outside your expected user base.
- Dataverse Export Operations: Initiated through Power Pages, matching data formations observed in leaked files.
Configure these alerts to trigger incident response procedures, not just log entries.
Common Pitfalls
Assuming Default Settings Are Secure: The Anonymous Users web role is dangerous when applied to sensitive tables. Don't rely on Microsoft to prevent this configuration choice.
Testing Only Through the UI: Attackers query API endpoints directly. Security testing must include unauthenticated API calls, not just UI interactions.
Treating Power Pages as "Just a Website": It's a direct interface to CRM and ERP data. Apply the same security rigor as database access controls.
Ignoring Decentralized Deployments: Power Pages is designed for business users, not just IT. Your governance model must account for portals deployed outside central oversight.
Overlooking Data Aggregation Risk: Even low-sensitivity tables can reveal patterns when combined. The District of Columbia Public Schools incident involved significant PII exposure.
Quick Reference Table
| Security Control | Check Frequency | Owner | Verification Method |
|---|---|---|---|
| Table permission review | Quarterly | Security Engineering | Automated scan of all Power Pages instances for tables assigned to Anonymous Users role |
| API endpoint testing | Monthly | Application Security | Unauthenticated queries to /_api/* endpoints across all portals |
| Access log analysis | Daily | Security Operations | SIEM alerts for bulk exports, sequential enumeration, anomalous IPs |
| Portal inventory reconciliation | Monthly | IT Governance | Compare discovered instances against authorized deployment list |
| Data classification validation | Per deployment | Data Governance | Verify all tables accessible through portal match approved sensitivity levels |
| Incident response drill | Semi-annually | CISO | Tabletop exercise simulating unauthorized Power Pages access |
Your configuration management database should track each Power Pages instance with its associated tables, web roles, and approved access scope. When an Information Security Incident occurs, you need to know immediately which portals could be affected, what data they expose, and who has access.
The ExfilSquad campaign shows that data extortion groups actively scan for these misconfigurations. Your security posture depends on finding them first.
