Azure AD Moves to Block OAuth App Hijacking

Azure AD App Property Lock Feature Blocks Updates to App Credentials

In a relatively unpublicized move, the Azure AD development group has closed a hole exploited by attackers who add their own credentials to registered apps. The new app instance property lock feature (preview) allows developers to lock sensitive properties of apps. It’s intended for use by enterprise apps, which are the way that developers like Microsoft and Adobe install apps in other Azure AD organizations. The enterprise app stores app properties while the service principal created by Azure AD in the host organization holds the permissions assigned to the app in that organization. After provisioning the app into a new tenant, the developer can lock the app against change.

Why Attackers Go After OAuth Apps

In the past, attackers have been able to hijack an enterprise app by adding a credential like a X.509 certificate to the app. Unless the organization monitors the audit events created for application updates, the new credential will exist undetected and the attacker can use it to request Azure AD to issue an access token containing the permissions assigned to the app. Apart from its permissions, attackers don’t need any further access to the app. Instead, the attackers use the access token to access whatever data the permissions allow. In some cases, the attackers might access items in mailboxes; in others they might go after sensitive documents stored in SharePoint Online sites. Once they’ve compromised the target repository, the attackers can exfiltrate or wipe the data (potentially a Microsoft 365 “wiperware” attack).

Hijacking OAuth permissions assigned to apps is not a theoretical attack vector. It’s what was used in the Solarwinds campaign in 2021. The attackers generated an X.509 certificate and added it to Azure AD apps and used highly-permissioned apps to access data. Another example of OAuth app abuse is the September 2022 instance when attackers used an OAuth app to create an inbound connector to send spam.

Applying an Azure AD App Property Lock

The property lock feature allows developers to block any changes to some or all the sensitive properties for an app (the properties used in authentication flows). It’s important to emphasize that the property lock is not mandatory. Developers must apply it to their apps before the apps are used in other tenants.

You can lock properties for a registered app but cannot update enterprise apps created in your tenant by another organization (because an external organization owns the app). For instance, you cannot change the iOS accounts enterprise app used by Apple for some iOS device management, like the change needed to force the iOS mail app to use modern authentication.

To start, go to app registrations, select the app to lock and then access the authentication tab. The App instance property lock option is toward the bottom of the screen (Figure 1).

Click Configure and select the properties to lock (Figure 2).

Save the changes and the property lock is in force. Any subsequent attempt to update credentials will fail anywhere outside the home tenant.

Checking for App Credential Updates

Azure AD feeds audit information to the unified audit log, including events logged for app credential updates. Unfortunately, the information in the audit records follows an esoteric format that makes the data harder to interpret than it needs to be. Here’s a code snippet showing how to run the PowerShell Search-UnifiedAuditLog cmdlet to retrieve and report audit records for app credential changes.

$StartDate = (Get-Date).AddDays(-90)
$EndDate = Get-Date

[array]$Records = Search-UnifiedAuditLog -StartDate $StartDate -EndDate $EndDate -Formatted -ResultSize 5000 -Operations "Update application – Certificates and secrets management "
$Report = [System.Collections.Generic.List[Object]]::new() 
ForEach ($Record in $Records) {
 $AuditData = $Record.AuditData | ConvertFrom-Json
  $Mods = $AuditData.modifiedproperties.NewValue
  $ReportLine  = [PSCustomObject] @{
     Timestamp        = $Record.CreationDate
     User             = $AuditData.UserId
     AppName          = $AuditData.Target[3].Id
     Modified         = $AuditData.modifiedproperties.NewValue }
 $Report.Add($ReportLine)
}

The same information is available in the Azure AD audit log (Figure 3).

Attacks Don’t Stop When a Hole Closes

Although regrettable that the holes existed in the first place, it’s good that Microsoft is closing off one of the vulnerabilities exploited by attackers with the Azure AD App property lock. It’s an example of the chess game played out between the attackers and defenders around the protection of cloud services. Now that this hole is closing, attackers will consider their next move. Stay vigilant and keep checking the audit log to detect suspicious events!

---

Learn about protecting your Microsoft 365 tenant by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand features like the Azure AD app property lock and the most efficient ways to protect your data.