Low-Code Exposure: ExfilSquad Targets Misconfigured Microsoft Power Pages in Mass Extortion Wave
Executive Summary
A newly emergent cybercrime and extortion group known as ExfilSquad has claimed responsibility for exfiltrating sensitive records from over 15 major corporations, municipal governments, educational institutions, and public sector agencies. Independent cybersecurity research published by threat intelligence firms Fortra and Veranix, and verified by Cybersecurity Dive, confirms that the threat group successfully exploited permissive anonymous read access configurations within Microsoft Power Pages (formerly Power Apps portals) connected to Microsoft Dynamics 365 (D365) and Microsoft Dataverse backend tables.
Unlike traditional ransomware intrusions or sophisticated zero-day software exploits, this mass data exfiltration campaign required zero malicious binaries, zero malware execution, and zero authentication bypasses. Instead, threat actors utilized automated web API scraping utilities against public-facing low-code web portals that inadvertently exposed underlying relational database tables to anonymous internet users.
High-Profile Impacted Entities
Organization
Estimated Data Volume
Record Count
City of Atlanta
36 GB
3 million records
Microsoft (Internal Assets)
130 GB
8 million records
Frontier Airlines
43 GB
2.4 million records
Allstate
15 GB
657,000 records
U.K. Department for Education
440 MB
600,000 records
Sources verify these figures and the involvement of various universities and public school systems (Cybersecurity Dive).
Deep-Dive Technical Analysis
Understanding the Microsoft Power Pages & Dataverse Architecture
Microsoft Power Pages is a software-as-a-service (SaaS) platform within the Microsoft Power Platform ecosystem that enables organizations to rapidly build, host, and publish data-centric, external-facing business websites. Under the hood, Power Pages integrates natively with Microsoft Dataverse, a scalable cloud data storage engine that houses business data for Microsoft Dynamics 365 enterprise resource planning (ERP) and customer relationship management (CRM) applications.
Dataverse stores data in structured tables (entities) composed of rows (records) and columns (fields). When developers create a Power Pages site—such as a municipal citizen service portal, a customer support ticketing hub, or a student enrollment form—they configure Table Permissions to govern which user web roles can view, create, edit, or delete records within specific Dataverse tables.
The Root Cause: Permissive "Anonymous Users" Table Permissions
The core vulnerability exploited by ExfilSquad is rooted in the configuration of Table Permissions associated with the built-in Anonymous Users Web Role.
* Default vs. Custom Table Exposure: When web forms or lists are configured in Power Pages to allow unauthenticated public interactions (such as submitting an initial intake form or searching a public directory), developers must assign Table Permissions to the "Anonymous Users" role.
* Over-Scoping Read Privileges: In many deployments, developers inadvertently grant Global read access across an entire Dataverse table rather than scoping access strictly to specific records or utilizing authenticated roles. Furthermore, entire table schemas—containing sensitive columns such as full legal names, Social Security numbers (SSNs), email addresses, home addresses, dates of birth, internal case logs, and financial transaction identifiers—are exposed through backend OData and REST API endpoints.
* Public OData Feed Enumeration: Power Pages exposes standardized OData feeds (e.g., /_api/[entity_set_name]) to dynamically populate client-side JavaScript grids and forms. If Table Permissions are enabled for anonymous users with read privileges, these endpoints can be queried directly by any external HTTP client without requiring a valid login session or API key.
Automated Reconnaissance and Bulk API Exfiltration
ExfilSquad deployed automated reconnaissance scanners across known IP ranges and domain namespaces associated with Microsoft Power Pages (*.powerappsportals.com, custom domains, and Azure Front Door endpoints). The threat actor's automated toolchain executed the following multi-stage scraping workflow:
1. Portal Discovery & Schema Fingerprinting: Scanners queried common Power Pages metadata endpoints to identify active Dataverse entity sets, checking for exposed tables such as contacts, accounts, leads, incidents, and custom organization entities.
2. Anonymous Access Validation: Automated scripts sent unauthenticated GET requests to the /_api/ OData endpoints with $select and $top query parameters to determine if records were returned without authentication challenge redirects.
3. High-Concurrency Bulk Data Harvesting: Once a misconfigured entity was identified, the attackers systematically paged through the entire database table using OData pagination tokens ($skip, $skiptoken), dumping millions of records into local CSV/JSON databases at machine speed.
Because the traffic utilized legitimate, documented web APIs over HTTPS on port 443 without triggering signature-based intrusion detection systems (IDS) or web application firewall (WAF) exploit patterns, the exfiltration blended into routine public web traffic and evaded traditional perimeter defenses (Cybersecurity Dive).
Threat Actor Profile & Extortion Playbook
ExfilSquad represents an evolving trend of pure-play data extortion groups that bypass ransomware encryption in favor of stealthy, bulk cloud data harvesting followed by high-pressure public shaming.
ExfilSquad Attack & Extortion Lifecycle
Stage
Action
Reconnaissance
Scan Internet for Power Pages & Dynamics 365 Public Portals
Vulnerability Identification
Identify Misconfigured "Anonymous Users" Read Permissions on Tables
Exfiltration
Execute Automated OData Scraping to Dump Full Dataverse Entities
Shaming
Publish Victim Roster on Dark Web Leak Site with Countdown Deadlines
Pressure
Release Sample Data Proofs to Pressure Executive Leadership
Extortion
Demand Cryptocurrency Extortion Payments to Prevent Full Public Leak
Key Elements of the ExfilSquad Playbook
* No Malware Footprint: The group does not deploy ransomware payloads, backdoors, or memory-resident implants. This eliminates the risk of early detection by Endpoint Detection and Response (EDR) agents and simplifies operational overhead.
* Public Shaming & Staggered Deadlines: On July 26, 2026, ExfilSquad published an initial roster of approximately 15 victim organizations on their dark web leak portal, setting an initial negotiation deadline of August 5, 2026 (Cybersecurity Dive).
* Sample Proof Releases to Counter Skepticism: When organizations and security analysts initially questioned the validity of the claims, ExfilSquad published targeted file samples containing verified employee details, citizen service requests, and customer records to force victims to the negotiation table.
* Focus on Regulated Entities: By targeting government agencies, regulated enterprises, and tech leaders, the group leverages strict data protection frameworks (GDPR, state privacy laws, and federal breach disclosure regulations) to maximize extortion pressure.
Systemic Risks of Low-Code / No-Code Web Platforms
The Power Pages extortion wave underscores a broader industry crisis surrounding low-code and no-code (LCNC) application development:
1. Decentralized Development ("Citizen Developers"): LCNC platforms empower business units and non-technical staff to rapidly build web applications without formal security architecture reviews or code security audits.
2. Implicit Trust and Default Visibility: Developers often treat access control as an afterthought, conflating the user interface (UI) view with actual database-level API permissions. Hiding a column or table on a web page does not restrict backend API access if Table Permissions permit anonymous reads.
3. The API Blind Spot: Traditional security monitoring tools frequently monitor for OS vulnerabilities and software exploits (CVEs), while remaining blind to authorization misconfigurations on legitimate SaaS APIs.
Actionable Mitigation and Hardening Playbook
Enterprise security teams and administrators utilizing Microsoft Power Pages, Power Apps, Dynamics 365, and Dataverse must immediately execute the following defensive measures:
1. Audit and Enforce Table Permissions
* Mandatory Table Permissions: Ensure that Enable Table Permissions is strictly toggled ON for every list, basic form, advanced form, and Web API configuration in Power Pages.
* Review the "Anonymous Users" Web Role: Inspect all Table Permission records assigned to the "Anonymous Users" role. Disallow Read, Append, Append To, Write, or Delete privileges on any Dataverse table containing customer, employee, financial, or internal operational records.
* Scope Down to Account or Contact: Where public users must view data, require user authentication and scope Table Permissions to Account or Contact relationships rather than Global organization-wide scope.
2. Column-Level Security & Column Masking
* Implement Column Security Profiles: Apply Dataverse Column Security Profiles to sensitive fields (e.g., SSN, BirthDate, EmailAddress) to prevent them from being queried via backend APIs, even if a table requires limited public access.
3. Power Platform Admin Center Governance
* Run Power Platform Advisor Access Reviews: Leverage the Power Platform Admin Center and Microsoft Defender for Cloud to run automated tenant-wide configuration audits to identify all public-facing Power Pages sites with unauthenticated Dataverse access.
* Enforce Environment Routing & DLP Policies: Isolate production Dynamics 365 databases from sandbox or prototype Power Pages portals. Apply strict Data Loss Prevention (DLP) connector rules across all environments.
4. Web Application Firewall (WAF) & API Rate Limiting
* Deploy Azure Front Door / WAF: Place Power Pages portals behind Azure Front Door with integrated WAF rules to detect and throttle high-frequency OData paging requests ($skip, $top).
* Monitor API Anomaly Telemetry: Configure Azure Monitor and Microsoft Sentinel alerts to flag anomalous spikes in unauthenticated HTTP GET requests directed at /_api/ endpoints.
Reference Sources
* Cybersecurity Dive: Researchers confirm breach claims by data-extortion group