[$15,000 Bounty] M365 Phish: Power Platform Privilege Escalation and Pivoting
Exploring the M365 Power Platform as a means of privilege escalation and flexing control over a phishing victim's SharePoint, OneDrive, Outlook, and Microsoft Teams data.
- Introduction
- A warning for Power Users / Power Platform end users
- Background & Overview
- Power Platform Vulnerabilities and Exploitation
- Taking it further, the external threat
- Detection + Remediation
- Disclosure and Resolution Timeline
- VULN-056239: SharePoint PrivEsc - Additional Reading
- Resources
Introduction
This post is my exploration into escalating privileges using the Power Platform (Power Apps + Power Automate), gaining access to a target user’s SharePoint, OneDrive, Outlook, Private Teams chats, and potentially more. While this is primarily an internal threat (employee -> employee), I will show how a compromised Power User’s workstation can be leveraged to harvest credentials and deploy a malicious app from a cli (PowerShell, in this example), despite the Power Platform being primarily web-based tooling. I hope to share some of my recent research to shed light on this topic in an effort to ensure security staff and users of the Power Platform are aware of these techniques and their implications.
This blog post will detail a few thoughts, however, viewing the POC videos will provide a more concrete understanding of the issues. POC Code and App/Flow templates can also be found in this unpolished GitHub Repo.
A warning for Power Users / Power Platform end users
What permissions do you think you are consenting to when accepting the permissions prompt below?
Surprisingly, this originally granted full read/write access to SharePoint/OneDrive (documents stored in the Files tab in Teams), and Outlook, most of this has been fixed. However, consenting to this permission will still grant the app creator the ability to create mail rules, read/send mail, and otherwise control your mailbox/calendar (docs).
For example, this malicious HTTP Action is still possible from the M365 Users Connector (typically used to pull profile information) and will allow an attacker to push a mail rule into the victim’s Outlook mailbox to hijack mail flow (note: forwarding won’t work with external domains, however, since this is an insider threat the mail could be sent to another internal M365 mailbox).
It should be noted that the M365 Users connector does have access to a user’s inbox through the /me/messages endpoint, which can be leveraged during the flow runtime to search for interesting emails in the victim’s inbox and send them back to the attacker.
I have already reported 3 separate reports to Microsoft and included details about what I believe are improperly scoped tokens being used here, to which I have received no feedback other than a closed ticket and bounty payment. At this point, I can only assume Microsoft accepts this functionality. Please be aware that if you accept permissions from the M365 Users connector, you are granting access to your Outlook emails.
If you read no further, just know that granting consent in Power Apps will grant the malicious creator of that app access to your account for 30 days for whatever permissions are accepted. Accepting even a seemingly innocuous permission such as the M365 Users connector can result in severe consequences.
Below is a video POC to demonstrate how accepting a malicious Power App’s permissions request can lead to account takeover across several M365 products.
To reiterate, always validate the source of the apps you are consenting permissions to as they will run actions as you and have access to your data. Additionally, be vigilant of the data you store in these locations (e.g.: avoid keeping personal tax documents, passwords, etc. in your corporate OneDrive/SharePoint).
Background & Overview
The Office/Microsoft 365 suite (specifically Power Apps + Power Automate) have become incredibly powerful and gives “Power Users” in an organization the ability to quickly develop useful tools to help their business operate with agility. These low code solutions (web application builder Power Apps + workflow automation Power Automate) are becoming more mainstream as businesses continue to adopt the suite, putting these tools in the hands of their employees. It has been reported that Power Platform adoption has exploded, used by 500,000+ companies (~97% Fortune 500 companies) and 20M monthly active users - these products have been heavily adopted by big business.
The Power Platform, by design, is meant to empower citizen development. Due to this, the number of people with permissions to create M365 applications has gone up and these users can be thought of as privileged users. Insider threat statistics show that insider threats account for a non-trivial number of security incidents and should be taken extremely seriously.
Anyone with an E3 or E5 license, by default, can freely create a Power App and send it to anyone in the organization who is licensed to consume it. Therefore, companies that have licensed a large portion of their staff with these licenses should be aware of the potential insider threat this attack vector outlines. For companies that have adopted the Power Platform, a large portion of their staff may be licensed to perform this attack on their peers. If the majority of the company is not licensed, even entry-level staff such as IT Interns may have the necessary privileges to execute these payloads - granting such privileges to entry-level staff makes it easy for threat actors to gain a foothold by placing a low-level employee on the right team. It may be wise to incorporate the Power Platform into a company’s security awareness training as the tooling becomes more heavily adopted.
Much like the Office suite (Word, Excel, PowerPoint, etc.) has been abused with embedded macros for phishing purposes, the Power Platform offers some interesting ways to abuse its extensive feature set leading to some unexpected repercussions. While endpoint antivirus has become increasingly decent at stopping malicious Office docs, detection of strange cloud activity (for example, actions taken when interacting with the Power Platform or other M365 Delegated permissions grants) is far less robust. At the moment, trying to log and alert on delegated Graph API usage seems non-existent, meaning these types of activities are largely undiscoverable to my current knowledge; Advanced Hunting, Unified Audit Logs, and Entra Logs all fail to track the necessary data to pick up on these attack scenarios.
For anyone curious about malicious Office document tampering, there has been some amazing research into techniques such as vba stomping or the newer vba purging. I would recommend looking into them as they are quite fascinating.
Power Platform Vulnerabilities and Exploitation
While some of these issues have been patched, I will outline some interesting functionality uncovered throughout my Power Platform research. I hope this post brings value to security researchers and anyone curious enough to read through this content.
The below POC video was submitted to Microsoft and highlights issues found in the Power Platform including improperly scoped backend tokens, path traversal, and a lack of verbose permission consent prompts. This example demonstrates gathering private Teams Chats through a path traversal in the Get a Team action. I also place a malicious file in a user’s OneDrive through the M365 Users connector. From here, the malicious document may be synced to their desktop; in this way, it may be possible to obtain RCE if the victim attempts to execute these malicious files. We could also replace a trusted Office file (e.g.: Excel) with a duplicate that has a malicious embedded macro for the same effect.
Another POC video (below) shows a hypothetical attack scenario. The video describes additional attack path options such as hijacking Outlook to automatically route Power Platform emails to the trash of victim users such that it may be possible to hijack Shared Flows that may contain other connections for further escalation.
Issue: Improperly scoped backend tokens
I want to highlight that this issue is not fixed, in my opinion. The last I tested, it was still possible to create mail rules via the M365 Users connector. However, it does look like the M365 Groups V2 HTTP Action will restrict actions to only operations affecting M365 groups, so I am hopeful this will be patched completely in the future for all actions or at the very least the Power Platform can incorporate more verbose/granular permissions prompts.
Issue: Path traversal
This issue has been patched, but I have bypassed the patch twice now so if anyone else finds a new bypass this may become an issue again.
I will note that my original path traversal was successful with the classic: ../
Bypass 1 involved url encoding a single .: %2e./
Bypass 2 involved using a backslash: %2e.\
I resolved Bypass 1 after contacting Microsoft directly via. an M365 support ticket. Bypass 2 was found after that ticket was closed and I was receiving no responses from that email thread nor comments on my previous bug bounty submission. I submitted Bypass 2 as a separate bug bounty submission and was paid out $5,000 - so while I reached out via. support ticket to resolve Bypass 1 in the interest of my company in hopes of a faster resolution. I share my experience with bug hunters to show that it may be more profitable as an individual to submit bypasses as separate bugs (plus bug bounty channels may be triaged faster for remediation than a typical support request).
Due to the structure of bug bounty platforms, as a full-time bug bounty hunter, it may be prudent to not overshare potential remediation considerations to farm the same bug multiple times. Especially if the program does not reach out for validation of a fix before closing out the report. Additionally, it may also be worthwhile to look for previous public issues and try to bypass implemented protections.
Taking it further, the external threat
While Power Apps and Power Automate are usually used by internal employees, I did explore the idea of a remote attacker gaining access to a Power User’s workstation and what the escalation could look like. Below is a video POC demonstrating what a remote attacker that has gained access to a Power Platform user’s machine can do; the attacker hijacks running instances of Outlook + Microsoft Teams to manage communications with secondary phish targets, dumps Power Platform credentials from the browser’s session storage of a currently active session by hooking the Chromium browser’s remote debugging port, and engages in secondary phishing campaigns for further escalation.
I will also add that another POC idea is to take the logged-in user’s Power Automate credential from the browser and dump all workflow definitions they have access to, looking for secrets/credentials to other services.
Dumping credentials + hijacking user sessions
While the video POC explored opening a Chromium-based browser (Chromium, Chrome, Edge, etc.) with the remote debugging port and harvesting a Power App refresh token by dumping local storage, I will note that an alternative would be to look on disk for files containing local storage data. My Windows machine seems to store local storage in blob files that contain plaintext refresh tokens that can be extracted via. regular expressions.
For example, harvesting MS Edge session storage located on Windows @
C:\Users\<username>\AppData\Local\Microsoft\Edge\User Data\Default\Local Storage\leveldb\...
This is a note to app developers that credentials and secrets (in this case, a refresh token) stored in the browser as cookies + local storage are easily retrievable beyond the boundaries of the running app. This is something to keep in mind when weighing the pros and cons of a product’s feature set. While it seems to be an accepted known risk that compromising a user on a machine yields access to their credentials, it should be noted that storing secrets in a browser’s localstorage does not have the same security risk as the cookie implementation.
Detection + Remediation
Unfortunately, I have not found a solid method of prevention or detection. Administrators can leverage the Power Automate API to iterate over workflows and analyze their definitions. However, this is quite manual and how do you identify a malicious app? It is recommended that M365 user activity is logged such that potentially malicious actions such as creating Outlook mailbox rules are correlated against other events to detect a potentially compromised account, however, Microsoft’s current logging solutions leave much to be desired here. Additionally, host-based detections such as browsers executed with the remote debugging port, unexpected reads on sensitive (credential) files, and other suspicious behaviors should also be logged and alerted on.
Education for end users and security awareness training are also important, users should be aware of these threats and encouraged to report suspicious behavior.
Disclosure and Resolution Timeline
- VULN-056239 | Critical | $5k bounty - SharePoint PrivEsc
- Opened: 2021-10-18
- Resolved: 2022-03-28
- VULN-086140 | High | $5k bounty - Path Traversal, Improperly Scoped Backend Tokens
- Opened: 2023-01-03
- Closed: 2023-03-06
-
Path Traversal bypass #1 (
%2e./), resolved via. Microsoft Support emails - VULN-101569 | High | $5k bounty - Path Traversal Bypass #2 (
%2e.\)- Opened: 2023-05-17
- Closed: 2023-06-28
VULN-056239: SharePoint PrivEsc - Additional Reading
My original report was after 6 months of me debating whether or not it was worth reporting: “is this a feature or a bug?”
My research started in early 2021 when exploring what I could do with the SharePoint HTTP action. Reporting the SharePoint Priv Esc issues to Microsoft resulted in a more verbose consent page. Months later, I discovered HTTP actions were added to other connectors (outlined in this post), found the path traversals, and explored the attack surface outlined in this post. I originally posted my SharePoint findings and, unsatisfied with the remediations, took my blog post down to contact Microsoft directly to ask if more work was being done to protect users. Now that I have communicated and my follow-up reports have been resolved, I am releasing this post and re-publishing my backdated SharePoint post /blog/2022/05/13/Abusing-SharePoint-and-OneDrive-Permissions-with-PowerApps-and-Flow.html if anyone is interested in the SharePoint specific attack path that is still possible at the time of publishing this post.