March 18, 2024 | Security intelligence

Application consent attacks: Patterns, detection, and mitigation

With contributions from Patrick Tohill.

Loading table of contents...

With CISA warning that Russia’s APT29 is increasingly targeting cloud services over traditional self-hosted, on-premise infrastructure, Field Effect analysts dug into our cloud telemetry to proactively hunt for threat-related activity based on the known TTPs and IoCs associated with APT29 and similar actors.

While we didn’t discover any IoCs related to APT29 in our telemetry, we did notice a surge in application consent attacks conducted against clients using Microsoft Azure cloud services in the first quarter of 2024.

What is an application consent attack?

An application consent attack, sometimes called an illicit consent grant, is when a threat actor creates an application within the target’s cloud environment using a legitimate but compromised account.

The threat actor then sends the target(s) a request for the malicious application to access protected resources and data on the user’s behalf using conventional phishing tactics. Once accepted by the target, the malicious app receives a token that can be used to access the protected resources from the appropriate cloud API.

The resources most often abused include sending/reading emails, changing mailbox settings, and accessing files, contacts, directories, and notes.

Screenshot 2024-03-18 105708

Image 1: Screenshot of permission request (Source: Microsoft)

Certain cloud environments, including Microsoft Azure, allow all users to consent to applications for permissions that don't require administrator consent by default.

For example, a user could consent to allow the app to access their mailbox but couldn't consent to unfettered read and write access to all files in the organization. However, in cases where a Global Admin account is compromised, the registration and consent grant apply tenant-wide, providing the malicious application access to all user data company-wide.

Successful application consent attacks can lead to various outcomes.

In some cases, threat actors use the attack simply to establish better persistence in to the compromised account. For example, the app will continue to provide the threat actor with access to the data/services the user originally consented to, even if the user changes the account password and/or enables multi-factor authentication (MFA).

In other cases, threat actors use the app to send phishing messages from the original compromised account to others within the cloud environment, enticing them to install the app as well, leading to further data compromise.

Lastly, the app can be leveraged by threat actors to send phishing messages from the original compromised account to external targets, potentially leading to business email compromise (BEC).

Application consent attack patterns

While reviewing telemetry associated with application consent attacks, we discovered a pattern of activity typically followed by threat actors.

Most of the attacks we observed began with attempts to log in to a valid cloud account from IP addresses associated with multiple VPN and VPS providers. These likely represent password spraying or brute-force attacks on cloud accounts that do not have MFA enabled. Conversely, some credentials could have been purchased from criminal marketplaces or stolen during a previous adversary-in-the-middle attack.

Once successfully logged on, we observed applications with verified publisher status, such as “PERFECTDATA SOFTWARE” and “eM Client”, being leveraged by threat actors to conduct application consent attacks. In one of the incidents we investigated, the threat actor logged into an account from an OVH VPS IP address and granted “eM Client” access to IMAP resources on behalf of the user. Shortly afterward, an inbox rule was created that automatically marked emails received as read and deleted them. Finally, the threat actor sent emails to over 400 recipients from the victim’s email account.

We also observed threat actors creating their own cloud applications in the target’s Azure environment. In these scenarios, the threat actor leveraged existing access to a compromised account to add the application and configured a password for the application before granting permissions to the account.

These actions suggest the actor was likely attempting to establish persistent access to the compromised account and in some cases configured an MFA authenticator device for the compromised account. Some of the threat actor-created application names appeared innocuous, such as ".." and "test", while others were likely designed to appear as though they were associated with legitimate services such as "s3" (Amazon s3) and "azRE" (Microsoft Azure).

The patterns and TTPs we observed align with those reported by other cybersecurity vendors who have also seen threat actors leveraging the “PERFECTDATA SOFTWARE” and other cloud applications to conduct application consent attacks in cloud environments.

Detection and mitigation tips

The threat posed by application consent attacks can be mitigated by implementing several basic security controls and policies:

Implement MFA: MFA makes it significantly more difficult for threat actors to leverage stolen account credentials. Often, threat actors will simply move on to targeting accounts that do not use MFA.

Restrict non-admin users from creating cloud applications: Restricting non-admin users from creating cloud applications would prevent threat actors from leveraging compromised user accounts to create malicious cloud applications.

Require administrator consent for risky permissions: Transferring control of granting risky permissions from users to administrators reduces the chances of malicious application consent requests getting approved, provided administrators properly scrutinize these requests.

Adopt an appropriate MDR solution: MDR tools can help detect and mitigate application consent attacks. For example, Field Effect’s MDR solution automatically notifies users of various characteristics of application consent attacks, including:

Abnormal logins from VPNs/VPSs and other suspicious IP addresses
The creation of cloud applications
Mailbox configuration changes

This automatic threat reporting and isolation, when configured, allows defenders to identify and counter threats in near real-time.

Indicators of compromise

The following VPN addresses were observed being used by threat actors to log in to cloud accounts and subsequently conduct application permission attacks:

2607:9000:0:51:[:]1e – MullVad VPN
45.91.23[.]132 – Express VPN
193.43.135[.]173 – Nord VPN
181.214.167[.]36 – Private Internet Access VPN
181.214.167[.]138 - Private Internet Access VPN / Starvpn
45.91.23[.]5 – Express VPN
62.3.36[.]118 – Nord VPN

The following VPS IP addresses were observed being used by threat actors to log in to cloud accounts and subsequently conduct application permission attacks: