Consent-Phishing - CraftedSignal Threat Feed

O365 Risk-Based Consent Disabled

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This alert focuses on the disabling of the "risk-based step-up consent" feature within Microsoft 365. When enabled, this feature requires additional authorization steps for users attempting to grant permissions to applications deemed risky by Microsoft. Attackers can exploit user consent to gain access to sensitive data. By disabling this control, adversaries can potentially trick users into granting permissions to malicious applications without triggering additional security checks, effectively bypassing a critical defense mechanism. This can lead to account takeover and data exfiltration. The activity is logged within Azure Active Directory and can be identified by changes to the 'AllowUserConsentForRiskyApps' setting.

Attack Chain

An attacker gains initial access to an administrator account, potentially through phishing or credential stuffing.
The attacker authenticates to the Azure Active Directory admin portal.
The attacker navigates to the Enterprise applications settings.
The attacker modifies the authorization policy using the "Update authorization policy" operation.
Specifically, the attacker changes the "AllowUserConsentForRiskyApps" setting from "true" to "false".
This change disables the risk-based step-up consent feature, lowering the threshold for application consent.
The attacker then uses social engineering or other phishing techniques to trick users into granting consent to a malicious OAuth application.
Upon successful consent, the attacker gains access to user data and other resources authorized by the user, leading to data theft or further compromise.

Impact

Disabling risk-based step-up consent can significantly broaden the attack surface within an organization's Microsoft 365 environment. Successful exploitation can lead to widespread data breaches, impacting potentially thousands of users. This can lead to regulatory fines, legal liabilities, and significant reputational damage. The lack of step-up consent increases the likelihood of successful OAuth phishing attacks, which are becoming increasingly prevalent.

Recommendation

Enable the Sysmon config and ingest O365 management activity events to allow for proper detection coverage.
Deploy the Sigma rule O365 Block User Consent For Risky Apps Disabled in your SIEM to detect instances where the "risk-based step-up consent" setting is disabled.
Investigate any detected instances of this setting being disabled, focusing on the user (user field in the logs) who made the change and the context surrounding the event.
Educate users about the risks associated with granting application consent and how to identify potentially malicious applications.

Azure AD User Consent Blocked for Risky Application

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This analytic identifies instances where Azure Active Directory (Azure AD) has automatically blocked a user's attempt to grant consent to an application flagged as risky. The detection focuses on the "Consent to application" operation within Azure AD audit logs, specifically looking for system-driven block events. This automated blocking mechanism is a crucial defense against malicious OAuth applications attempting to gain unauthorized access to organizational data. Early detection of these blocked consent attempts allows security teams to investigate potentially compromised user accounts and identify malicious applications targeting their organization. The observed activity highlights Azure's proactive security measures and emphasizes the need for immediate investigation to understand the context and take preventive measures against sophisticated consent phishing attacks, particularly those leveraging techniques similar to the 365-Stealer.

Attack Chain

Attacker registers a malicious OAuth application in Azure AD.
The attacker crafts a phishing email or uses other social engineering methods to lure a target user into clicking a malicious link.
The link redirects the user to the Azure AD consent page for the attacker's malicious application.
The user, if not cautious, is prompted to grant the application permissions to access their account and data.
Azure AD's risk analysis engine detects that the application is risky based on various factors (e.g., publisher reputation, requested permissions).
Azure AD blocks the user's attempt to grant consent to the application.
The event is logged in the Azure AD audit logs with a "failure" result and a reason indicating "Risky application detected".
Security team investigates the blocked consent attempt, the user involved, and the characteristics of the flagged application.

Impact

A successful consent phishing attack can lead to the compromise of user accounts, data exfiltration, and further malicious activities within the organization. While Azure AD's blocking mechanism prevents immediate compromise, repeated attempts or successful circumvention could lead to significant damage. This detection helps identify users who are being targeted and applications that are attempting to infiltrate the organization, reducing the potential for widespread damage.

Recommendation

Deploy the provided Sigma rule to your SIEM and tune it for your specific Azure AD environment to detect blocked consent attempts for risky applications (rules).
Investigate any triggered alerts by examining the user, application, and requested permissions involved to determine the potential impact (search).
Review Azure AD Identity Protection settings to ensure that risk-based consent policies are properly configured and blocking risky applications (references).
Educate users about the risks of granting consent to unfamiliar applications and how to identify potentially malicious requests (references).

Azure AD User Consent Denied for OAuth Application

hello@craftedsignal.io — Wed, 03 Jan 2024 10:00:00 +0000

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

Attacker registers a malicious OAuth application in Azure AD.
Attacker crafts a phishing email or uses other social engineering methods to trick a user into visiting a malicious link.
The link directs the user to the legitimate Azure AD consent page for the malicious application.
The application requests permissions, such as access to email, contacts, or files.
The user, recognizing the suspicious nature of the application or requested permissions, denies consent. The properties.status.errorCode field will contain the value 65004.
The Azure AD sign-in activity logs record the denied consent event, capturing details about the application, user, and permissions requested.
The security team analyzes the denied consent event to determine if it represents a legitimate user concern or a potential attack.
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.