Last week saw the launch of a new cybercrime group calling themselves ExfilSquad. What makes this incident particularly relevant for the readers of this newsletter is that their attacks appear to focus on Dynamics 365 and Power Platform based systems. Namely, Power Pages websites.

Out of the 15 claimed victims, the most interesting one is Microsoft themselves. Following the July 26 publication of the breaches on the group’s own Tor-based server, a post from @exfilsquad (now removed account) on X mentioned @MsftSecIntel and shared a screenshot of one record that surely looks familiar to anyone working intimately with Dataverse:

As of now, there is no proof that the group has actually managed to steal data from Microsoft. What we have is posts on social media from infosec experts like Kevin Beaumont saying the portal listings are real. Shortly after, there’s also been reports on traditional media like The Guardian where UK organizations like the Department for Education and the UK police have confirmed the incident:

These days, it’s hardly a shocking piece of news that bad actors have compromised IT systems that organizations use for managing customer data. It happens all too often. Literally right as I’m writing this week’s newsletter, I see a push notification on my phone screen about my personal details having leaked in a data breach of the e-scooter company Ryde. At least the European data protection legislation forces companies to make the customers aware of it.

The more interesting aspect to think about is A) how did the attackers get in and B) could we as IT professionals have done something differently to stop this from happening? And also, C) is the tech vendor behind the targeted products doing everything it should to help in keeping customer data safe?

Before it was even called Power Pages, there was a research report published by UpGuard in August 2021. “By Design: How Default Permissions on Microsoft Power Apps Exposed Millions.” I wrote about this in my personal blog, back when I didn’t yet have a weekly newsletter:

Power Apps Portals, the earlier version of Power Pages, and what had evolved from the AdxStudio Portals ISV acquisition Microsoft made in 2015, was always about simplifying the task of making CRM data available online. You could say it’s built to expose your Dataverse data to the outside world — while naturally offering many ways to control the detailed access rights.

If you really wanted to, you could just build a regular website with Power Pages that shows content like pages, posts, videos and so on. No self-service scenarios or logins needed. An example of such a site would be Keeping It Real with Power Platform: a website for the video series hosted by Leon Welicki, Vice President of Power Platform Core at Microsoft.

Now, Leon works at Microsoft and presumably doesn’t have to pay for the licenses of this website. If you’re not in a similar position, you really need to do the math on Power Pages licensing costs before embarking on a similar journey. Back when the Power Apps Portals licensing model of page view packages was replaced with the Power Pages model of authenticated + anonymous users, I calculated that my former company’s website bill would have jumped from €84 to €1.011 per month. (No, of course we weren’t managing our team blog via Power Platform but through WordPress like normal people do.)

What this demonstrates, though, is that there are legit use cases for publishing data from various different types of Dataverse tables onto a public website. Whereas records like support cases will surely be behind a login, supporting information like knowledge base articles, product information, even pricing details — those may all be intentionally exposed to anonymous visitors. The product makes this easy, just a web CMS tool should.

The 2021 incident where “misconfigured Power Apps from Microsoft led to more than a thousand web apps accessible to anyone who found them”, as reported by Wired, was caused by a product decision making it too easy to leave authentication off from tables. Specifically, the OData feeds used to be enabled by default:

Was this a vulnerability in Microsoft’s software? No. Was it a poor design choice for a business application portal experience that was sold as a way to make your Dynamics 365 CRM data accessible to external parties? I’d say it was. At least since big orgs like American Airlines, Ford, New York MTA — and again, Microsoft themselves, failed to catch the misconfiguration for their production portals. Leading to sensitive information like MSFT payroll data being available to anyone who just knew which URLs to look for:

Microsoft did take this episode pretty seriously. Even if the direct blame was on the organizations that hadn’t properly configured the security settings of their portals, this was obviously not the kind of publicity anyone selling an enterprise-grade low-code platform wants to see. The defaults were changed to require explicit removal of authentication instead. There were tools like Portal Checker (now called site checker) built to make scanning sites with anonymous access enabled easy for organizations. As Power Apps Portals later evolved into Power Pages, the maker experience was designed to surface key security information clearly, rather than expecting the website developers to know which checkboxes to hunt for.

Finally, a deprecation note was posted: “Starting June 2022, using OData feeds to interact with data via RESTful web services will be deprecated. We recommend that you migrate to the Power Pages Web API.” The OData feed feature was to be removed by June 2026. I think it took a bit longer than that, but it seems the OData endpoints have now been technically disabled for old sites:

The above screenshot is from the repo of my XrmToolBox Plugin Catalog website. If you recall, I vibe coded an alternative experience on top of the official XrmToolBox.com site that Tanguy Touzard is managing. It’s a simple GitHub Pages site that was doing a daily pull of the plugin table data from an OData URL, powered by GitHub Actions (free!!!). On August 2nd, the refresh stopped working. But luckily the new Web API was available for the same table, so I opened an issue about it, assigned it to GitHub Copilot, and the updates are now flowing in again to the xrm.jukkan.com website.

If this would have only been a story where OData feeds were the villain, we could now say “The End” and let Dynamics 365 and Power Platform customers live happily ever after. But of course technology doesn’t quite work like that. In July 2026, we still have large organizations getting their confidential business data stolen and used for extortion by malicious actors who apparently knew more about Power Pages than the customers did:

Out of the 15 claimed victims that were mentioned on ExfilSquad’s data leak site on July 26th, we’ve now seen the first ones come out and admit real data has been exposed. After the two major public institutions in the UK, Swedish residential developer Bonava is the latest to issue a public statement about a data breach:

This doesn’t mean everyone on the ransom list is an actual target. Frontier Airlines, for example, had already announced a data breach had happened a couple of weeks before ExfilSquad came along and added the airline to their extortion list, too. Is it the same or a different incident? Who knows!

The online rumors about Microsoft’s 8 million leaked records have been saying it’s from a support portal most likely aimed at their partner organizations. With more than 500,000 partner organizations and millions of end-customers served through the channel, an accumulated CRM system could easily contain that many contacts. There’s been some mentions about passwords being included, which sounds a bit strange — until you realize that the end-users of Power Pages are represented as contact records. With a local-auth password-hash field in there, whether it’s actually populated or not.

But let’s move from speculation to explanation: how does this still keep happening even when OData is gone? The security researchers have once again helped us with illustrating the possible path leading to data exposure in the new Microsoft Power Pages Web API world. The November 2024 report from AppOmni discusses the problems that may remain, even when you disabled anonymous access to sensitive Dataverse tables in your web portal.

One simple trick that can help attackers gain more access to the underlying data is to simply register as a user. For B2C support and self-service portals, it’s pretty likely that becoming a valid customer with a login to the site isn’t too difficult. Bonava: “I’m interested in finding a new apartment.” Frontier Airlines: “I want to fly to…” UK police: “I want to use the Ask The Police service.” Microsoft: “I am a partner and I want to open a ticket”. Easily establishing a user identity is often the whole point that makes the online services useful.

Why does this matter technically then? Because in Power Pages that automatically moves you from one web role to another. Instead of operating with the Anonymous Users Role, you are now interacting with the Web API through the Authenticated Users Role. Those will have different table permissions by design, given how some functionality needs to be only visible after logging in. When open registration is not technically blocked, it may be possible to even perform this action when the UI doesn’t directly reveal the option. So, every attacker must be assumed to at least have the Authenticated User level at their disposal.

What happens next? Endpoint discovery and enumeration. Since the attackers know what are the standard features and operating logic of all Power Pages based sites, they don’t need to randomly try and guess URLs that would open the doors to data. There’s plenty of default tables to try with the /_api/EntitySetName pattern.

The fun part is how the Web API will give different error codes for tables that don’t exist vs. those that the user isn’t authorized to read. This gives a useful signal to anyone who wants to go through all the available doors to see if something has been left unlocked. Maybe not the whole table, but at least some columns of it. For an example of what this means in practice, have a look at the “Identifying exposed tables and exploiting wildcard columns” part of AppOmni’s great article.

The actual tasks needed to properly restrict access to data in a way that the logged-in user only has access to their own tickets and profile data, for example, is not technically a hard thing to do. The platform provides tooling for it. The real question is: does the developer working with the platform sufficiently understand how the security model is implemented in Power Pages and Dataverse specifically?

Back in 2021 when the “OData gate” was revealed, a typical reaction from the online audience was to say “those damn citizen developers shouldn’t be allowed to create these portals in the first place”. I’ve already seen the same reaction in 2026 for the ExfilSquad incident. And my response is the same today as it was five years ago: “just look at the list of impacted organizations”.

Sure, it is risky to allow non-technical business people anywhere near Power Pages maker tools. But c’mon: do you believe the portals for the UK police or big airline companies have been built by citizen devs? Of course not! There must have been a small army of consultants and/or internal developer resources working on the project. Many surely had experience from developing websites on different tech stacks. The main question is: did they thoroughly understand Power Platform solution architecture?

It doesn’t matter if there’s a simple GUI for things, or if things are done in raw server config files and through traditional coding tools. Just because something looks easy to approach does not mean it isn’t a complex beast that is hard to master. In the age of agentic coding, I’d even say that anything you can’t edit and validate via a CLI is a big risk for misconfigurations slipping through into production.

It would of course be safer if we didn’t have to build any external routes through which people outside the organization’s firewall can access CRM data. That would also block most possibilities of making the customer experience better by offering digital channels that don’t require calling a human agent and asking them to open the CRM records instead. Also, no: putting an AI agent in the middle to use CRM and accept prompts from the outside world isn’t going to make things any more secure by default. You’ll only introduce new attack vectors.

Now, I’m not saying that AI is useless here. In fact, I remain optimistic that LLMs are a force multiplier for the solution builders already today, whereas the autonomous scenarios for end-customer engagement may be a bit further away still. Let’s look at what Microsoft has been doing on this front.