ExfilSquad Targets Misconfigured Microsoft Power Pages Portals

ExfilSquad is a data extortion group first observed on July 26, 2026, after listing 15 organizations as alleged victims.

The list includes private companies, municipalities, schools, and government bodies. Based on the evidence reviewed by VenariX, at least part of the actor’s activity appears consistent with the exfiltration of data from Microsoft Power Pages portals connected to Microsoft Dataverse.

VenariX has not identified evidence of ransomware deployment, malware use, lateral movement, or exploitation of a software vulnerability. The available evidence instead points to anonymous users being granted overly broad access to Dataverse records through public Power Pages portals. Microsoft documents that assigning Dataverse table permissions to the Anonymous Users web role makes the affected data accessible to anyone visiting the site.

Our Research

VenariX reviewed data samples associated with 11 of the 15 organizations named by ExfilSquad. Across all 11 samples, the data structure and field formatting were consistent with Microsoft Dataverse exports.

Two findings lend additional credibility to at least some of the actor’s claims:

1. Frontier Airlines, one of the organizations named by ExfilSquad, confirmed on July 9, 2026, that an unauthorized party accessed a data storage account containing personal information. Frontier did not attribute the incident to ExfilSquad.

2. The City of Houston, also named by ExfilSquad, was linked to a public-facing Microsoft Power Apps portal used by Houston 311, the city’s non-emergency service request system. VenariX confirmed that the portal returned incident records without authentication, and the exposed records were consistent with data published by ExfilSquad.

These findings support the assessment that the actor may have used the same access path across multiple victims. However, the available evidence does not yet confirm that every organization was affected through an exposed Power Apps portal or the same configuration issue.

Likely Attack Path

The reviewed data is most consistent with extraction from public Microsoft Power Pages portals that were configured to allow anonymous users to read Dataverse records. Microsoft documents that Power Pages can expose Dataverse tables through its portal Web API using the /_api/<EntitySetName> route, and that access is governed by table permissions assigned through web roles.

A likely flow is:

Public Power Pages portal → Anonymous Users web role → Broad table permission → Power Pages Web API or legacy OData feed → Dataverse data export

Microsoft Power Pages can expose Dataverse records through routes such as:

https://<portal>/_api/incidents
https://<portal>/_api/contacts
https://<portal>/_api/accounts
https://<portal>/_api/emails
https://<portal>/_api/annotations

Microsoft states that when the Anonymous Users web role is granted access to a table, any visitor to the site can access that table’s data. It also documents that table permissions apply to records accessed through forms, lists, Liquid, and the Power Pages Web API.

Legacy OData feeds may provide another public access path. Microsoft recommends testing /_odata from an unauthenticated browser session because enabled feeds may be available anonymously depending on the portal’s security configuration.

The data samples published by ExfilSquad and reviewed by VenariX contain Dataverse and OData structures, including:

• @odata.etag

• @OData.Community.Display.V1.FormattedValue

• @Microsoft.Dynamics.CRM.lookuplogicalname

• Standard Dataverse entities such as contacts, accounts, incidents, emails, annotations, leads, system users, and business units

These structures, together with the anonymously accessible Houston 311 endpoint identified during the investigation, support the assessment that at least some of the data was extracted through a Power Pages API or OData interface. They do not identify the exact endpoint used for every organization or confirm that all 15 claims involved the same configuration issue.

What Data May be Exposed

The reviewed samples contained a wide range of personal, financial, employee, customer, and operational data.

Personal and Identity Information

The samples included:

• Names

• Personal and business email addresses

• Phone numbers

• Residential and business addresses

• Dates of birth

• Nationalities

• Social Security numbers

• Tax identifiers

• Passport and identity document details

• Employee and customer identifiers

Financial and Banking Information

The reviewed records included:

• Bank account numbers

• Account-holder names

• Customer IDs

• Account types and status

• Credit limits

• Accounts receivable balances

• Refund details

• Partial payment-card information

• IBAN and SWIFT details entered into support cases

Employee and Organizational Data

The samples included:

• Employee IDs

• Job titles

• Departments

• Managers

• Business units

• Office locations

• Supplier and contractor classifications

• User permissions

• Mailbox configuration

• Microsoft Entra object IDs

• Dynamics system-user IDs

Customer and CRM information

The reviewed records included:

• Customer and partner contacts

• Sales leads

• Opportunities

• Product interests

• Marketing preferences

• Account numbers

• Complaint records

• Support cases

• Oracle and ERP identifiers

Travel, Medical, and Public Service Information

Some of the most sensitive records involved:

• Booking confirmation codes

• Flight numbers and dates

• Medical conditions

• Disability information

• Service-animal requests

• Passport and driver’s license references

• Medical notes

• Municipal service requests

• Water and sewer account numbers

• Billing disputes

• Exact addresses

• Latitude and longitude

• Citizen complaint narratives

The reviewed files appear to be samples rather than complete exports, so the total number of affected records cannot be determined from the available evidence.

Why Microsoft Power Pages Can Expose Data

Microsoft Power Pages allows organizations to create external-facing websites that use data stored in Microsoft Dataverse. These sites can allow users to submit, view, or update Dataverse records, including through forms and lists.

Access to Dataverse data is controlled through table permissions and web roles. Microsoft states that when the Anonymous Users web role is assigned to a table permission, the table’s data becomes visible to anyone visiting the site.

The risk increases when anonymous users are granted privileges such as:

• Read

• Update

• Delete

• Global access to records

Microsoft documents that table permissions can control record access and privileges, including read, write, and delete, and that Global access applies the permission broadly to records in the selected table.

Organizations should therefore avoid granting anonymous users read access to sensitive Dataverse tables, including tables containing incidents, contacts, accounts, emails, attachments, system-user data, financial information, or customer records. For public intake forms, organizations should limit anonymous users to Create permission wherever the business process does not require them to retrieve existing records.

Recommended Actions

Organizations using Microsoft Power Pages or legacy Power Apps Portals should review public sites, anonymous permissions, Web API settings, and enabled OData feeds.

Disable Unnecessary Anonymous Access

In the Power Platform admin center, review:

Resources
→ Power Pages sites
→ Governance Controls
→ Disable anonymous access

This control can prevent unauthenticated users from reading Dataverse data while allowing public users to continue submitting forms.

Review Table Permissions

In Power Pages Design Studio, review:

Security
→ Table permissions

Remove the Anonymous Users role from permissions granting:

• Read

• Update

• Delete

Restrict the Power Pages Web API

Review site settings such as:

Webapi/<table>/enabled
Webapi/<table>/fields

Disable API access for tables that do not require it.

Examples:

Webapi/incident/enabled = false
Webapi/email/enabled = false
Webapi/annotation/enabled = false
Webapi/systemuser/enabled = false

For tables that must remain accessible, use explicit field allowlists rather than:

Webapi/<table>/fields = *

Check Legacy OData Exposure

Test public access to:

/_odata
/_odata/<collection>

Disable unnecessary feeds and verify that enabled collections enforce table permissions.

Validate the Fix

From a private browser session with no portal cookies, test endpoints such as:

/_api/incidents?$top=1
/_api/contacts?$top=1
/_api/accounts?$top=1
/_api/emails?$top=1
/_api/annotations?$top=1
/_odata

A properly restricted endpoint should return an authorization error or no record data.

Preserve Evidence and Review Logs

Before making changes, preserve current configuration and relevant logs.

Review:

• Power Pages table permissions and web roles

• Web API site settings

• Power Pages administrative activity

• Dataverse auditing

• Microsoft Entra sign-ins

• Service-principal activity

• WAF and reverse-proxy logs

• Requests containing /_api/, /_odata/, $top, $select, $filter, or pagination parameters

• Repeated sequential requests and high-volume downloads

VenariX Assessment

ExfilSquad should be treated as a credible data extortion threat actor. The reviewed samples, the structure of the exposed Dataverse data, and the publicly accessible Houston 311 endpoint provide technical support for at least part of the actor’s claims.

The available evidence points to exposed Microsoft Power Pages and Dataverse environments as the likely access path in several cases. It does not yet confirm that every claimed victim was affected in the same way.

Organizations using Power Pages should take the claims seriously, review anonymous access and table permissions, and investigate for signs of bulk data extraction. VenariX will continue to track ExfilSquad, validate its claims, and update its assessment as new evidence becomes available.

Track ExfilSquad activity, affected organizations, evidence, and related incidents in VenariX.

Explore VenariX →