Rogue Azure AD Guests Can Steal Data via Power Apps

Guest accounts in Azure AD (AAD) are meant to provide limited access to corporate resources for external third parties — the idea is to enable collaboration without risking too much exposure. But enterprises may be unknowingly oversharing access to sensitive resources and applications with guests in Azure AD, paving the way for data theft and more.

An upcoming presentation at Black Hat USA in August will detail how a toxic combination of easily manipulated default guest account settings and promiscuous connections within Microsoft's low-code development platform known as Power Apps can kick open the door to giving guest accounts wide-open access to the corporate jewels. Power Apps provides a rapid development environment for businesses to build custom apps that connect various online and on-premises data sources (such as SharePoint, Microsoft 365, Dynamics 365, SQL Server, and so on).

Researcher Michael Bargury, CTO of Zenity, will present his findings in a session on Thursday, Aug. 10, entitled, "All You Need is Guest." He noted in the session writeup that guests can use undocumented APIs to gain access to corporate SQL servers, SharePoint sites, KeyVault secrets, and more; they can also create and control internal business applications to move laterally within the organization.

"From the perspective of the blue team defending an organization, I'm hoping to show that inviting guests carries a lot more risk than they might think," he says. "This is the first research that I'm aware of that shows that guests can actually gain access to data, not just gain an understanding of your directory or something like that."

A Two-Step Path to Malicious Azure AD Access

Bargury says the potential exposure can be achieved through a two-step process. The first part of his demonstration at Black Hat USA will show how easy it is to take a guest account with default settings — ones that essentially show access to no applications — and, by using a few cheap manipulations that include creating trial licenses and canceling them, give a guest user visibility into the default environment for Power Apps, which exists in that AAD tenant.

Once that visibility is established, guest users will then be able to see all of the application connections created in Power Apps that have been marked as "shared with everyone" by developers.

"The root cause of the problem I'm showing comes when somebody has created or shared an application using something that Microsoft calls 'share with everyone,'" Bargury notes. "And when you share with everyone, you might think that it's shared with everybody in your org, but essentially it means everyone in your AAD tenant, which includes guests."

In turn, those apps connect to data in the background that could be sensitive.

"These are resources in Azure AD. They can be in on-prem, they could be people's own personal accounts that have been overshared across the organization," he says.

By default, just because a guest account could see those connections doesn't necessarily mean they could use them to get at data, thanks to limitations that Microsoft has created through protections like its Power Platform DLP controls. However, Bargury will demonstrate how he's able to get around those protections as the second step of the attack process.

"Once you are in and you can see the things that have been overshared, you need to be able to use them," he says. "I'm using research that has been done by others that allows me to basically reach out to internal Microsoft APIs with existing user authentication. The reason why I'm able to go through each of these connections and dump the data behind them is because I was able to peel off the front-end APIs for Power Platform and figure out the infrastructure behind them. And I'm essentially just reaching out directly to the infrastructure in terms of the front-end APIs, which means that I can a) circumvent defenses; and b) leave no logs."

Limiting Cyber Risk From Promiscuous Oversharing

Bargury says his talk will sound the alarm on how severe this problem is and also provide the audience with the tools to get a handle on the risk posed by this exposure. He'll also walk the audience through configurations that they can change to limit the scope of guest access in their AAD environment, and he'll talk about how to detect the manipulations that could lead to this toxic oversharing to guest accounts.

"One of the key things that I'm doing here is using research to gain authentication tokens to those internal APIs," he says. "And that's an event that you can configure AAD to log. If you find that the user, especially guest user, has provisioned for themselves an authentication token to an internal Microsoft API that should not be exposed, then this should be a red flag."

As a part of the talk Bargury is going to drop a new tool called PowerGuest, an exploratory auditing tool that will help both blue and red teamers understand the true scope of guest access within an AAD tenant.

The other important point he'll focus on is that defenders really should start to gain a better understanding of the connections and credentials opened up in their AAD environments through Power Apps.

"If you are building things on top of low-code platforms, you need to understand that it's very easy for you to share credentials and identities across different users. When you create an application and you share it with other people, then they end up getting access to the underlying connection, the underlying data source," says Bargury, who tackled this concept in a different piece of research presented earlier this year at RSA Conference.