You accidentally missed the last meeting with your boss and don’t want it to happen again. So, you click a button in your browser to install an Azure Application. This app will organize your calendar and send reminders, so you don’t miss any more meetings. And it works. You get regularly reminded and are now always on time. 

Unbeknownst to you, the application has a dark side. In the background, the Azure app has compromised your Office 365 environment and transferred your abilities to an unknown attacker. This attacker can now read all of your OneDrive files, send emails on your behalf, read your emails, and even create additional users.

Note: I wrote this article as an intern during research conducted at Praetorian in the summer of 2021. For similar content, check out their blog.

This situation is not the result of a vulnerability that you can patch. It happens when users install a malicious Azure application. 

We made one of these malicious Azure applications to demonstrate the damage it can cause. Before we reveal our app, let us explain some background information.

What is an Azure Application?

Azure applications are web applications that help you and your company do stuff in Office 365. If you have ever used Office 365, you have used Azure apps. They are created through the Azure App Service, hosted in the cloud, and interact with Office 365 through Azure APIs. One of these APIs is the Microsoft Graph API, which can interact with a user’s OneDrive, Outlook, and more. By writing a malicious Azure Application, an attacker can access all these resources once a user has enabled the application. 

Because this attack happens in the browser, it gives the attacker two extra advantages. First, it bypasses the Virtual Private Network (VPN) protections of Office 365. The application can access the Microsoft API even when a VPN protects the user’s Office 365 environment. Second, the attack does not require conventional malware, so traditional EDR solutions are useless (although our POC described later integrates malware to achieve full machine compromise).

Threat actors in the wild have successfully exploited these attacks, and they are difficult to counter. We will explore defensive options, but first, let us look at how an attacker can paralyze an Office 365 environment through a malicious Azure App.

When we heard about the potential of malicious Azure Apps, we set out to develop a Proof of Concept (POC) Azure application that executed a single high-impactful attack. While this application only scratches the surface of what is possible, it demonstrates severe potential—introducing our new tool, SeAzure.

What does SeAzure do?

SeAzure (pronounced seizure) is our malicious Azure Web Application. When a user adds SeAzure, it steals every file in their personal OneDrive and replaces them with identical weaponized versions. The next time the user (or anyone else in the company) downloads these files and enables macros, the malicious payload will execute. 

Currently, the payload just opens the calculator app. But, a malicious payload could execute a ransomware attack or connect back to our Command and Control servers to give us complete control over the victim’s machine. SeAzure does this through OAuth 2.0 permissions granted by the victim upon application authorization. 

We would like to open-source SeAzure to demonstrate this process in code, but seeing how easily a malicious actor could weaponize SeAzure, we have decided to keep it private. It is still important to note that developing malicious Azure apps is no “secret sauce.” Apps like the one made by Varonis described in this Malicious Azure App blog post, as well as PwnAuth by FireEye, are other examples of high-impact malicious Azure apps. With some development experience, any attacker can create an app like SeAzure– although theirs won’t have as cool of a name.

How Does a Victim Authorize SeAzure?

SeAzure begins when an Office 365 user navigates to SeAzure’s URL. For demonstration purposes, let’s assume that our victim Dave works at a large company. The attacker gives Dave a call, routing her phone number through a service that makes it look like she is calling from inside Dave’s company. She tells Dave that she is from HR, letting him know that his Workday Azure App is out of date, and sends him the link to the “updated” application. When Dave follows the link, this is what he sees:

The name and logo of the application are entirely customizable, which makes it very easy for SeAzure to masquerade as a legitimate application. Here SeAzure is impersonating “Workday,” a popular Azure app. 

Being a good employee, Dave wants to be updated as soon as possible. So Dave clicks “accept.” Poor Dave. SeAzure redirects Dave to a Workday confirmation page, and the attack begins.

What Happens During the Attack?

Currently, Dave’s OneDrive looks like this: 

We have opened testtesttest.doc to display the content, which we will get back to later. 

Immediately after Dave’s acceptance, SeAzure creates a new blob storage container and copies files from Dave’s OneDrive to our blob storage container using the Microsoft Graph APIs. Within a few minutes, we have all of Dave’s files. We could have stopped and searched Dave’s files for sensitive information, but to explore SeAzure’s potential, we decided to go further. 

Time to Weaponize

Once SeAzure has stolen the files, the next step is infection. All infection happens locally so that the victim’s network sees as little malicious traffic as possible. For this purpose, we created a Golang binary called SeAzureHelper, which is manually run on our local machine (not in the cloud). Once SeAzure has stolen all of Dave’s files and transferred them to our blob storage container, we run SeAzureHelper. 

First, SeAzureHelper calls the Microsoft Blob Storage APIs to download the stolen files from our blob storage container. SeAzureHelper then locally adds malicious macros to all .doc and .xls files (for those interested, here is Michael Weber’s open-sourced tool to add macros to .xls files). 

Once SeAzureHelper has added the macros, the application calls Microsoft Blob Storage APIs to upload the infected files from our machine back into a blob storage container we control. Finally, SeAzureHelper sends a GET request to SeAzure on a secure URL to inform the web application that the files are weaponized. When the request is received, SeAzure prepares for the final stage of the attack.

Uploading Infected Files Back to the Victim’s OneDrive

Once SeAzure has been pinged, it uses the Microsoft Graph API to replace each .doc and .xls file in Dave’s OneDrive with the infected copies. Here is Dave’s OneDrive after the infection has occurred:

There is one way for Dave to notice the tampering. The “Modified” column will show that the uploaded files were recently modified. We made the POC using Dave’s private files. However, targeting company-wide shared files may be a better approach as any user will not know the last time a file was supposed to be modified. Regardless, the newly infected identical copies are now correctly situated inside Dave’s OneDrive.

Did it Work?

The next time Dave downloads and opens testtesttest.doc or xltest.xls, he will see the following screen. If he clicks “enable macros,” then our payload (in this case, calc.exe) will execute. Swap out the calc.exe payload with one that connects back to our command and control servers, and we would have complete control over Dave’s machine.

Notice that the word document looks the same as before it was infected; in fact, all files will look identical to their previously innocent copies.

So What Else Can Malicious Azure Apps Do?

Malicious Azure Applications can do much more than steal and infect Dave’s files. They can also read his emails (password resets, anyone?), send emails on his behalf, and even create external users. From ransomware to PII theft, malicious Azure Apps can cause damage.

Defending Against SeAzure

As any defender has probably realized, SeAzure leaves a trail. Both the “file-modified” field and SeAzure’s need to run macros can be a giveaway to an astute victim. Additionally, the macro payload must be able to bypass EDR. While a sophisticated attack can reduce the risk of these identifiers, it is still possible that SeAzure can be caught- although probably not by Dave. 

Remember, however, that we built SeAzure to demonstrate impact, not to be stealthy. We wanted to extend the attack vector of stealing files as far as possible, with no concern about noise. Imagine if a malicious Azure App stopped after stealing all personal and shared files. Or if it stopped after reading emails. It would be tough to detect this behavior in a large company. So how does one defend against malicious Azure Apps?

Defending Against Malicious Azure Apps

These attacks have a different digital footprint than traditional malware attacks, so detection is challenging. The principles go back to the basics- log, restrict, and educate. Microsoft documentation recommends performing weekly audits to detect signs of an attack by looking for overly permissive apps. Once a defender has identified a suspicious App, they should investigate immediately by looking through the logs. 

To reduce the probability of an attack, create strict OAuth App Policies and select specific permissions that users are allowed to consent to through Microsoft’s user consent settings. This ensures that if an application requests permissions outside the set scope, it will require administrative approval. Lastly, create protocols for distributing resources like Azure App links; and make Dave take a class that tells him never to open content he receives from a method outside of these protocols.

Indications of a Broader Attack Service

Let’s step back. We’ve seen the damage caused by malicious Azure apps, but these kinds of attacks are not limited to Office 365 and Azure. They are just a small part of a broad attack surface: the browser. 

Open-sourced tool Weaklayer aptly describes the browser as “The New Operating System,” which is why browser detection and response is a growing field addressing browser security. Tools like Weaklayer are creating what is essentially EDR for the browser. Their goals include increased traffic visibility, threat databases, extension and app store monitoring, and real-time protection. 

Some tools will even perform logo matching, which uses visual AI to scan logos for potential phishing attacks (this would work well against an app like SeAzure that is trying to impersonate Workday). While recommending an exact solution is outside the scope of this post, this class of tools will be an excellent first-line defense against these kinds of attacks. As tools like these develop, expect them to play an integral role in browser security.

Until browser EDR is more fully defined, defenders should apply protections like the ones used for Azure applications across all browsers and cloud services. Within the Chrome App store, use their enterprise policy to ensure that sensitive websites are deny-listed from being accessed by Chrome apps and extensions. Within Amazon Web Services, allowlist applications that need to access sensitive S3 buckets. 

These defenses depend on attention to detail – one mistake is all an attacker needs to pivot from the browser to the cloud. Eventually, a browser EDR solution may handle these problems. For now, apply every protection you can. And if it comes down to being late for a meeting or installing a sketchy Azure app to manage your calendar- be late.

Want to hear more? Subscribe to the official John IV newsletter to receive live, monthly updates of my interests and passions.