Zenity Helps Microsoft Identify and Remediate Critical Security Risk in Power Automate Desktop

About seven months ago at Defcon, Zenity CTO Michael Bargury presented security research that discovered and outlined a way to take over Microsoft Power Automate enabling bad actors to send ransomware to connected machines by using Power Automate as it was designed. By simply taking over an endpoint, our research showed that attackers can run their own payloads and execute malware by assigning machines to a new administrative account using a basic command line. Within this attack path, bad actors could also exfiltrate data, build keyloggers, and essentially control the browser. 

At the time, Microsoft issued a statement saying that end users simply needed to update the system, and that any machine with antivirus protections would be able to sniff out such an attack path. They continued that security teams simply needed consistent policies across their organizations and tenants. However, things are never quite that straightforward, particularly within large organizations. Since Defcon 30, many others have piled on this initial research from Zenity and discussed the ease at which Power Platform could be used by bad actors. The initial research and its offshoots showcased just how easily any user could perform this type of living off the land attack. In the new world of low-code/no-code development, where everyone has developer-like power, proper governance and security visibility is needed. 

As a result, Microsoft has just released tenant restrictions for Power Automate Desktop (PAD) machine registration, making it harder for malicious actors to use PAD to command and control, exfiltrate data, and run local commands using trusted executables. These restrictions aim to control which tenants are allowed to run PAD scripts on your machines and are, in our eyes, a correct walkback to the initial response over the Zenity research released last year. It is an important step to help control unauthorized access and actions within Power Platform, but there are still additional things that should be considered from a security perspective.

In addition to realistic goals like educating end users to be vigilant on updating software and endpoint protection, there are also some unrealistic things here that we would advise. There is no such thing as a utopic kingdom where  all domains and tenants are neatly organized, and there are no pre-existing infected devices. We would advise the following…

First, is maintaining continuous visibility over all low-code/no-code platforms, as Microsoft is certainly not alone in this new world of low-code/no-code development. By establishing a deeper understanding of ‘who is doing what’ within these platforms, it can greatly help security teams maintain control over their environments.  

Second, the new restrictions change the default behavior so that non-privileged users (on v2.24 or later) cannot register a malicious tenant if it is detected that the machine is already registered, or if the machine is domain-joined. This is certainly good progress on the part of Microsoft, but there are a few things coming from the Microsoft recommendations that we want to call attention to so that security teams have the full scope of what is needed. We would also recommend removing local administrator rights from endpoints, as the defenses here introduced by Microsoft still enable non-administrators to evade these controls if they have local admin. 

Finally, constantly assessing the risk of low-code/no-code development to ensure that as users of all technical backgrounds and expertise are leveraging these tools, that security teams have insights as to the potential harms of each new resource, will help keep attackers at bay. 

As always, you can keep up with the latest news and research within the world of low-code/no-code development on our blog, or by getting in touch with us here.