Azure AD User Consent Denied for OAuth Application

This detection identifies instances where a user has denied consent to an OAuth application within an Azure AD environment. The rule specifically looks for Azure AD sign-in activity events with error code 65004, which indicates that a user has denied consent to an OAuth application. Monitoring these denied consent actions is crucial because it can signify that users are recognizing potentially suspicious or untrusted applications. A successful attack leveraging malicious OAuth applications can lead to data breaches, unauthorized actions, and compromised email servers. Several resources detail this threat, including Microsoft's guidance on protecting against consent phishing and Altered Security's analysis of 365 Stealer. Detecting and understanding these denials helps defenders refine security policies and enhance user awareness to prevent successful OAuth attacks.

Attack Chain

1. Attacker registers a malicious OAuth application in Azure AD.
2. Attacker crafts a phishing email or uses other social engineering methods to trick a user into visiting a malicious link.
3. The link directs the user to the legitimate Azure AD consent page for the malicious application.
4. The application requests permissions, such as access to email, contacts, or files.
5. The user, recognizing the suspicious nature of the application or requested permissions, denies consent. The properties.status.errorCode field will contain the value 65004.
6. The Azure AD sign-in activity logs record the denied consent event, capturing details about the application, user, and permissions requested.
7. The security team analyzes the denied consent event to determine if it represents a legitimate user concern or a potential attack.
8. Based on the analysis, security policies are updated, and user awareness training is refined to prevent future attacks.

Impact

A successful OAuth application attack can grant unauthorized access to sensitive data, including emails, contacts, and files stored within the victim's Azure AD environment. Depending on the permissions requested by the attacker, they may be able to impersonate the user, send emails on their behalf, or modify data. While this detection focuses on denied consent attempts, understanding the frequency and context of these denials helps proactively identify and block potentially malicious OAuth applications before they can be successfully deployed. A compromised user account through malicious OAuth applications can lead to significant data breaches and financial losses.

Recommendation

• Deploy the provided Sigma rule Azure AD User Denied OAuth Consent to your SIEM and tune it based on your environment to detect potential malicious OAuth application usage in your Azure AD environment.
• Investigate any alerts generated by the Azure AD User Denied OAuth Consent rule to determine if the denied consent event is legitimate or indicative of a potential attack.
• Review and update Azure AD OAuth application consent policies to minimize the risk of users granting consent to malicious applications, as referenced in the Microsoft documentation on protecting against consent phishing.
• Use the references on 365 Stealer and malicious OAuth applications to improve threat intelligence and user awareness training programs.