Entra ID OAuth Application Redirect URI Modified
editEntra ID OAuth Application Redirect URI Modified
editIdentifies modifications to OAuth application redirect URIs (ReplyUrls) in Entra ID. Adding an attacker-controlled redirect URI to an existing trusted application allows interception of OAuth authorization codes when users authenticate through that application’s normal login flow, enabling token theft without requiring a new application registration or consent event.
Rule type: query
Rule indices:
- logs-azure.auditlogs-*
Severity: medium
Risk score: 47
Runs every: 5m
Searches indices from: now-9m (Date Math format, see also Additional look-back time)
Maximum alerts per execution: 100
References:
Tags:
- Domain: Cloud
- Domain: Identity
- Data Source: Azure
- Data Source: Microsoft Entra ID
- Data Source: Microsoft Entra ID Audit Logs
- Use Case: Identity and Access Audit
- Tactic: Persistence
- Tactic: Credential Access
- Resources: Investigation Guide
Version: 1
Rule authors:
- Elastic
- descambiado
Rule license: Elastic License v2
Investigation guide
editTriage and analysis
Investigating Entra ID OAuth Application Redirect URI Modified
A redirect URI addition to an existing trusted application does not generate a consent event and does not require registering a new application — both of which are commonly monitored. The modified application retains all existing user consents.
Possible investigation steps
-
Identify the actor who modified the application (
azure.auditlogs.properties.initiated_by) and verify whether the change was authorized by the application owner or a change management ticket. -
Review the specific URIs added by comparing
modifiedProperties.oldValueandnewValuefor theReplyUrlsfield in the audit event’starget_resources. - Geolocate and WHOIS the domain of any newly added URI — hosting providers, recently registered domains, or URL shorteners are strong indicators of compromise.
- Check whether the actor recently became an owner of this application: look for "Add owner to application" events in AuditLogs for the same application object ID.
- Review the application’s Graph API permissions — applications with Mail, Files, or directory scopes are the highest-value targets for redirect URI hijacking.
False positive analysis
-
Localhost and loopback URIs (
http://localhost:*,http://127.0.0.1:*) added by developers are expected in non-production applications. Verify the application’s sensitivity before closing. - CI/CD-driven URI updates typically originate from service principal actors, not human users.
Response and remediation
- Remove the unauthorized redirect URI via Entra ID > App registrations > Authentication.
- Revoke all tokens issued to the application since the modification timestamp.
- Review sign-in logs for the application for any sign-ins from unexpected sources after the change.
- If the URI was externally controlled, treat as a full OAuth token compromise for all users of the application and initiate token revocation and user notification.
Rule query
editdata_stream.dataset: "azure.auditlogs" and
azure.auditlogs.operation_name: "Update application" and
event.outcome: ("Success" or "success") and
azure.auditlogs.properties.target_resources.*.modified_properties.*.display_name: "AppAddress"
Framework: MITRE ATT&CKTM
-
Tactic:
- Name: Persistence
- ID: TA0003
- Reference URL: https://attack.mitre.org/tactics/TA0003/
-
Technique:
- Name: Modify Authentication Process
- ID: T1556
- Reference URL: https://attack.mitre.org/techniques/T1556/
-
Tactic:
- Name: Credential Access
- ID: TA0006
- Reference URL: https://attack.mitre.org/tactics/TA0006/
-
Technique:
- Name: Steal Application Access Token
- ID: T1528
- Reference URL: https://attack.mitre.org/techniques/T1528/