OAuth Apps Used to Automate Financially-Driven Attacks
The December 12, 2023 post for the Microsoft security blog covers how “Threat actors misuse OAuth applications to automate financially driven attacks.” The article describes how threat actors use OAuth applications planted in tenants to create virtual machines for crypto-mining, sending phishing email for business email compromise (BEC) attacks, and standard spamming. One of the targeted organizations ran up Azure compute fees of $1.5 million dollars for virtual machine usage.
Microsoft notes that most of the compromised accounts penetrated by attackers did not use multi-factor authentication (MFA). Enabling MFA is one thing. Making sure that the policies are enforced is another. The recent initiative to deploy Microsoft managed conditional access policies to “eligible tenants” might help, even if people still misunderstand and assume that all tenants receive these policies. Eligibility is determined by the presence of the necessary Entra ID P1 or P2 licenses in a tenant. If you don’t have at least Entra ID P1, you can’t use conditional access policies, and the Microsoft-managed policies won’t show up.
Compromised Accounts Create OAuth Apps
In all cases, attackers must compromise an account before they can create an OAuth app in the target tenant. The attacker’s task is easier if the compromised account has permissions, but even if the account is just a regular user account, it’s still useful because the attacker can use it to read directory information. To do this, the attacker must assign permissions to the app and seek consent to use those permissions to access data.
In some cases, tenants allow users to grant permission to apps. It’s best to configure the Entra ID user consent settings for a tenant to remove the ability of users to grant consent and either require administrator approval for all consents or to limit user consent for selected permissions to apps from verified publishers (Figure 1). In this context, the selected permissions are “low-impact,” meaning that they’re usually the permissions needed by users to access their own data but nothing else.
Reviewing App Permissions with Microsoft Defender for Cloud Apps
Tools are available to review the OAuth apps in a tenant. Microsoft Defender for Cloud Apps (now part of Microsoft Defender XDR) offers the ability to review the settings and consented permissions for OAuth apps. It can be surprising to discover how many OAuth apps exist in a tenant. For instance, Figure 2 shows the settings for the Microsoft Tech Community app. When people join the Microsoft Tech Community, they sign in and consent to access. That consent allows the app to read their profile details and email address.
Other apps do much the same thing, including apps used to register people for technical conferences like Microsoft Ignite.
Checking Consent Grants
Microsoft also recommends that administrators review consent grants within a tenant. If you allow users to grant consent for apps to receive some low-level permissions, administrators won’t know about these grants. However, they can check the audit log to find out when apps receive new permissions. I wrote about how to interrogate the audit log to find consent grant events a couple of years ago. Microsoft’s blog prompted me to go back and review the text.
The article contains a script that I’ve refreshed in two ways. First, I updated the use of the Search-UnifiedAuditLog cmdlet to accommodate the change Microsoft recently made to the way that the cmdlet works. That change was unannounced and can lead to situations where scripts that used to work perfectly well now do not retrieve all matching audit events. As Microsoft shows no appetite for reverting to previous behavior, it’s important to check scripts that use the Search-UnifiedAuditLog cmdlet to make sure that they work as expected.
Second, instead of simply returning an app identifier, the script now resolves the identifier into an app name. This can either be the name of a registered app (created in the tenant) or the service principal for an enterprise app. As you can see in Figure 3, it’s obviously easier to recognize an app name than it is to interpret the GUID returned for an app identifier!
The number of permission grants to the Microsoft Graph Command Line Tools app is high. This is the service principal used to hold permissions granted for interactive sessions with the Microsoft Graph PowerShell SDK. Over time, this service principal can accrue many permissions and it’s wise to keep an eye on this aspect and remove permissions (or reset the service principal) if necessary. Also consider securing access to the Graph SDK so that only selected users can run interactive sessions.
You can download the updated script from GitHub.
Attempts to Compromise Accounts Continue
Threat isn’t going to go away. Blocking basic authentication for Exchange Online connection protocols removed some tried-and-trusted methods for attackers to compromise user accounts. Attackers simply changed gear and try other methods to compromise accounts and they will keep on trying until they get in. That’s why it’s so important to use multi-factor authentication with a strong authentication method (like the Microsoft authenticator app or FIDO2 key) to stop attacks. But it’s also important to verify afterwards and make sure that no sneaky OAuth app appears in your tenant.
Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.
