Low-code development platforms open the way for greater independence and efficiency for business users. Unfortunately, they sometimes also open the way for attackers, as a result of poor low-code security practices, especially as low-code application security tries to catch up with traditional application security.
Last year, Microsoft’s Detection and Response Team (DART) published the timeline of an attack which leveraged Power Platform, Microsoft’s low-code platform. Using live-off-the-land techniques, the attackers were able to exflitrate sensitive corporate data and maintain complete Office 365 access for 240 days!
This post presents an in-depth analysis of the attack. We will use the small bits and pieces of information (see end of post for a list of sources) that were published to try and understand what happened, and how users of low-code platforms can apply better security controls to prevent similar attacks from happening.
As mentioned above, the attackers were able to maintain a persistent and complete Office 365 access for 240 days. During this time, the attackers were able to discover sensitive data, achieve strong persistence and exfiltrate data – all without the need to install any malware or access the corporate network. As traditional security solutions are based on either host or network agents, this type of attack was very hard to discover, to the extent that it took a security response team more than seven months to complete the investigation and oust the attacker.
Let’s start with a summary of the raw details:
|Target||A “Large Multinational”|
|Adversary||Nation-state backed adversaries|
|Adversary reputation||This APT group targets organizations across multiple industries, including government agencies, financial institutions, and technology companies.|
|Entry point||Password spray|
|Exfiltration point||Microsoft Power Automate|
|Access level achieved||Office 365 Admin|
|Result||Systematic access and exfiltration of data as well as sensitive emails.|
|Time persisted||240 days|
|Time investigated||More than 7 months|
As you can see, this attack went deep. Attackers were able to remain persistent within the environment for more than seven months while the security investigation was already ongoing. It is unclear how much time the attacker remained undetected before the investigation even started.
DART has published a slide which summarizes the chain of events:
Note that the attackers were able to execute an entire successful campaign without ever installing malware and hardly generating any network traffic directly. From the Cyber Kill-Chain perspective, the attackers started with #Delivery and #Exploitation via a Password Spray attack, skipped #Installation, and continued to leverage Office eDiscovery and Compliance Search for #Actions-On-Objective and Microsoft Power Automate for #Command-And-Control.
Many details are still missing, for example:
- What were the attackers able to find using eDiscovery and Compliance Search?
- How did the attacker use Power Automate to orchestrate the process?
- How did they avoid detection when exfiltrating the data?
Let’s try to reproduce the attack and come up with possible answers as we go.
How did it happen? Reproducing the attack
Step 1: Obtain confidential information
Microsoft 365 compliance center offers eDiscovery tools to comply with legal requirements for identifying and delivering specific data across the Office suite. As Microsoft puts it:
“Electronic discovery, or eDiscovery, is the process of identifying and delivering electronic information that can be used as evidence in legal cases. You can use eDiscovery tools in Microsoft 365 to search for content in Exchange Online mailboxes, Microsoft 365 Groups, Microsoft Teams, SharePoint Online and OneDrive for Business sites, and Skype for Business conversations, and Yammer teams. You can search mailboxes and sites in the same eDiscovery search by using the Content Search tool. And you can use Core eDiscovery cases to identify, hold, and export content found in mailboxes and sites.”
There are two tools that allow you to search over the entire tenant’s data: Content Search and Core eDiscovery. While these are separate services solving different business use-cases, both have a very similar user experience and search across the entire Office suite, including Exchange mailboxes, Teams Messages, SharePoint sites and Skype for Business messages.
According to DART, the attackers used these built-in eDiscovery tools to perform precision searches for both passwords and intellectual property. Here are a few examples of harmful search queries:
|Password reset emails||(subjecttitle:”password reset”)(senderauthor:@microsoft.com)(senderauthor:@namecheap.com)(senderauthor:@godaddy.com)(senderauthor:@amazon.com)(senderauthor:@zapier.com)||Exchange emails|
|Passwords shared between users||password (c:s) username (c:s) client id (c:s) client secret (c:s) certificate (c:s) .ppk||Teams, Skype and Office 365 messages, and Exchange emails|
|Legal documents||(size>1048576)(filetype=docx)(filetype=pptx)(filetype=xlsx)(filetype=pdf)legal||OneDrive and SharePoint documents, and Exchange emails|
|All communications to company CEO||(recipients:[email protected])||Teams, Skype and Office 365 messages, and Exchange emails|
These are only a few examples, however they demonstrate the tremendous power that these tools provide. If such capabilities fall into the wrong hands, they can be abused to move laterally by acquiring new credentials, obtain sensitive documents and perform a precision search to acquire all information of a single high privileged account.
Once you create an eDiscovery search, you can export its results periodically. Microsoft documentation clearly states that automated export is not supported, which might be related to the incident we are exploring. Today, Microsoft offers the eDiscovery Export Tool to access search results. The results are stored in an Azure storage account prior to being downloaded with the aforementioned tool, providing an opportunity for the attacker to access the files automatically. For this post’s purposes, we assume an attacker can fetch search results via an authenticated HTTP(s) request.
We now have a way to obtain valuable confidential information. It’s time to exfiltrate it and automate the process.
Step 2: Automate exfiltration by “living-of-the-land”
Power Automate is Microsoft’s low-code automation tool. It is available by default for every Office 365 user and is conveniently plugged into Office, SharePoint, Teams and Microsoft Dynamics. As Microsoft puts it:
“Empower everyone to build automated processes with flows in Power Automate. Use low-code, drag-and-drop tools and hundreds of prebuilt connectors that automate repetitive, mundane tasks with ease.”
Indeed, Power Automate is a powerful tool that gives business users and developers alike the ability to automate tasks, connect services and streamline an entire business process without writing any code. Most things a developer can do with scripts are now possible for both developers and business users with low-code.
When unprotected, however, Microsoft Power Automate gives power into the hands of attackers. An attacker can create a scheduled flow, export query results from Microsoft Compliance Centers and store the results in their own Azure blob storage (or any other exfiltration endpoint).
From the attacker’s perspective, Power Automate serves a dual purpose:
- Execute attack logic – instead of having to install malware on a compromised machine and risk detection by host-based security mechanisms, the attacker can leverage Office to orchestrate and run the malicious flow.
- Exfiltrate data – instead of having to find a route out of the corporate network while bypassing network security mechanisms, the attackers leverage an existing path to Office 365 and then use Office to send data elsewhere. Additionally, this method leaves no traces of the attack in the network logs, since Office is making all of the connections.
Preventing low-code platform abuse
Several things went terribly wrong in this attack. First and foremost, an administrator account should always have strong passwords and have multi-factor authentication (MFA) enabled. This would have prevented access to Microsoft compliance center capabilities and thus drastically limit the blast radius of the attack. Moreover, a few key log streams were disabled, hampering the investigation.
However, even if the attackers were not able to compromise an administrator account, they could still compromise other users within the organization with the same password spray attack. The malicious use of low-code platforms demonstrated above could be part of any attack, providing the attackers with a way to orchestrate and execute their malicious operations and exfiltrate data, all without leaving any trace on a host machine or the corporate network. Anything a user has access to is up for grabs for the attacker to automate.
This malicious strategy could easily be used with other low-code platforms, including Salesforce, ServiceNow, Zapier, IFTTT, Workato and MuleSoft.
While low-code platforms are not the only application development platforms that can be manipulated by attackers, they are particularly vulnerable to attack because low-code application security is still in its infancy, and organizations have yet to learn how to master low-code security best practices.
Traditional application security and IT security solutions cannot be used for these modern low-code business applications, and the equivalents for low-code are only just emerging. Application and information security professionals often have lower awareness of the unique risks of low-code platforms – or they have a keen awareness, but their hands are tied for lack of appropriate governance tools.
To prevent an attack like this or spot it as it unfolds, security teams must be familiar with the low-code platforms that are used within their organization and continuously monitor them for potential vulnerabilities and malicious activity. To succeed, they must realize that low-code is as much a revolution in SDLC as it is a new technology. They must also work alongside platform administrators to leverage platform governance capabilities that can restrict dangerous functionalities not required by users, like automated access to Office admin centers.
As always, there is a delicate balance to strike between improving security posture and enabling business workflows.
Let’s get practical
The following low-code platform security measures are simple fixes that you can (and should!) implement today:
- Ensure that your administration users have MFA enabled.
- Ensure that Office Audit Logs are enabled, including logs for Power Automate and Power App.
- Work with your Power Platform admins and consider restricting unused administrative connectors such as Power Platform for Admins, Power Automate for Admins, Power Apps for Admins, Microsoft 365 Compliance, Microsoft Defender ATP, Microsoft Security Graph, Azure AD, Azure AD Identity Protection and Security Center.
Low-code platforms are an amazing tool with tremendous ROI potential for the organizations that use them, which is one of the reasons why adoption is increasing so rapidly. To make sure you get the benefits of low-code without opening your organization to increased risk of attack, be aware of the issues. Set your priorities on putting appropriate security, visibility and governance strategies into place, so that you can open the door to business efficiency and growth, while closing the door to attackers.
- Incident Response Reveals Six Attackers in One Network, Secure World, March 12 2020
- Microsoft’s Response Team Finds SIX Advanced Threat Actors in Network of “Large Multinational”, Tech Monitor, 02 Mar 2020
- The 2020 Spotlight Report on Office 365, Vectra, Oct 2020
- Hidden Dangers of Microsoft 365’s Power Automate and eDiscovery Tools, cfn, Feb 2021
- Hidden Dangers of Microsoft 365’s Power Automate and eDiscovery Tools, Dark Reading, Feb 8 2021