The Attack Needed No Exploit. ‘Anonymous’ Already Had Read Access.
ExfilSquad’s leaked material is consistent with Microsoft Dynamics 365 and Dataverse exports. The strongest public assessment is not a Dynamics software exploit, but exposed Power Pages permissions that may have let an unauthenticated visitor read business records through an intended interface.
The distinction changes what defenders should look for.
An organisation can lose a large body of customer, employee or case data without malware, lateral movement or a broken software control. If a public portal gives its Anonymous Users role broad read access to a Dataverse table, the attacker may only need to ask the application for records it is already configured to return.
The data points to Dynamics, not to a confirmed exploit
ExfilSquad appeared publicly on 26 July 2026 with claims involving 15 organisations. Fortra’s Intelligence and Research Experts later analysed samples and the larger dumps published in August. The team found data structures and fields strongly associated with Microsoft Dynamics 365 CRM and ERP, and described the material as consistent with Dataverse exports.
Fortra found no evidence in the public material of an exploited Dynamics vulnerability, a conventional network compromise, lateral movement or an encryption payload. Its leading theory is that exposed or misconfigured Microsoft Power Pages sites allowed public read access to connected Dataverse data.
VenariX reached a similar but carefully bounded conclusion. It reviewed samples associated with 11 of the named organisations and found Dataverse and OData structures across them. During the investigation, it also confirmed that a public-facing Houston 311 portal returned incident records without authentication and that those records were consistent with material attributed to ExfilSquad.
That is strong support for the Power Pages route in at least part of the campaign. It is not proof that every victim was reached through the same endpoint or configuration. Neither Fortra nor VenariX claims a confirmed root cause for every organisation, and no public evidence establishes a software flaw in Dynamics 365 itself.
Anonymous read access can be the entire breach path
Power Pages is designed to put business processes on the public web. It can display and collect Dataverse data through forms, lists, templates and a portal Web API. Public access is therefore a legitimate product capability, not automatically a vulnerability.
The security boundary sits in web roles and table permissions. Microsoft’s documentation is explicit: when a table permission is assigned to the Anonymous Users web role, the data covered by that permission is visible to anyone visiting the site.
The same permission model protects records requested through the Power Pages Web API. If the API is enabled for a table and anonymous permissions are too broad, a visitor may be able to enumerate records through the portal’s own API route. Legacy OData feeds create another exposure path when they remain enabled and accessible without authentication.
Nothing in that sequence requires remote code execution. The service is functioning as configured. The security failure is that a public identity has been granted access to records the organisation did not intend to make public.
Low-code does not remove security ownership
Power Pages sits across several organisational boundaries. A business team may own the process, a maker may build the portal, a Power Platform administrator may govern the environment, and security may monitor identities and infrastructure. The Dataverse tables can belong to yet another application owner.
That division of labour makes anonymous access easy to miss. A permission added to make a form work during development can survive into production. A public site can outlive its original owner. A Web API setting can remain enabled after the component that required it has been removed. An old portal can continue to expose a live Dataverse environment even when nobody regards it as an active application.
Low-code changes who can create an internet-facing data path. It does not reduce the need for an owner, an access model, external testing, logging and incident response.
What Power Platform and security teams should do now
- Inventory every portal. Enumerate Power Pages sites and legacy Power Apps portals across all environments. Record the owner, business purpose, public status, authentication method, connected Dataverse environment and data accessed.
- Test from outside the trust boundary. Use a private browser session with no portal cookies and test pages, Web API routes and legacy OData feeds as an unauthenticated visitor. A portal that looks like a sign-in page can still expose data through a direct endpoint.
- Review Anonymous Users table permissions. Remove unnecessary read, update and delete rights. Pay particular attention to Global scope and to tables holding contacts, accounts, incidents, emails, notes, attachments, system users or financial data.
- Separate submission from retrieval. A public intake form may need permission to create a record. It rarely needs anonymous permission to read existing records. Grant only the action and fields the process requires.
- Restrict the Web API. Disable API access for tables that do not need it. Where access is required, use explicit field allowlists and avoid broad wildcard configurations.
- Use tenant governance controls. Where the business has no legitimate anonymous-read use case, block anonymous access to Dataverse data at the Power Platform governance layer rather than relying on every site owner to remain correct.
- Treat unexpected access as a possible incident. Preserve portal configuration, table permissions, audit data and relevant logs before making changes. Scope the exposed tables, fields, attachments, record counts and likely exposure period. Look for repeated pagination, filtering and high-volume requests.
- Follow the data. If exposed records contained credentials, API keys, access codes or financial instructions, rotate them. Involve privacy, legal and communications teams where personal or regulated data may have been accessible.
A permission error can be an intrusion
Security programmes are comfortable responding to malware, stolen credentials and unpatched vulnerabilities. A public application returning authorised responses to the wrong class of user can look less dramatic, even when the data loss is substantial.
That is the operational lesson from the ExfilSquad evidence. The absence of a confirmed exploit does not make the event benign. It means defenders must investigate application configuration, anonymous identities and data permissions with the same seriousness they apply to perimeter vulnerabilities.
The attack may have needed no exploit. If Anonymous already had read access, the breach path was the permission model.
Sources and further reading
- Fortra FIRE: ExfilSquad data extortion group ransoming Microsoft D365 data
- VenariX: ExfilSquad targets misconfigured Microsoft Power Pages portals
- Microsoft Learn: Power Pages security
- Microsoft Learn: Assign table permissions
- Microsoft Learn: Power Pages Web API overview
- Microsoft Learn: Site Checker configuration issues
