diff --git a/rules/integrations/azure/initial_access_consent_grant_attack_via_azure_registered_application.toml b/rules/integrations/azure/initial_access_consent_grant_attack_via_azure_registered_application.toml deleted file mode 100644 index da1197ef7a0..00000000000 --- a/rules/integrations/azure/initial_access_consent_grant_attack_via_azure_registered_application.toml +++ /dev/null @@ -1,126 +0,0 @@ -[metadata] -creation_date = "2020/09/01" -integration = ["azure", "o365"] -maturity = "production" -updated_date = "2024/12/05" - -[rule] -author = ["Elastic"] -description = """ -Detects when a user grants permissions to an Azure-registered application or when an administrator grants tenant-wide -permissions to an application. An adversary may create an Azure-registered application that requests access to data such -as contact information, email, or documents. -""" -from = "now-25m" -index = ["filebeat-*", "logs-azure*", "logs-o365*"] -language = "kuery" -license = "Elastic License v2" -name = "Possible Consent Grant Attack via Azure-Registered Application" -note = """## Triage and analysis - -### Investigating Possible Consent Grant Attack via Azure-Registered Application - -In an illicit consent grant attack, the attacker creates an Azure-registered application that requests access to data such as contact information, email, or documents. The attacker then tricks an end user into granting that application consent to access their data either through a phishing attack, or by injecting illicit code into a trusted website. After the illicit application has been granted consent, it has account-level access to data without the need for an organizational account. Normal remediation steps like resetting passwords for breached accounts or requiring multi-factor authentication (MFA) on accounts are not effective against this type of attack, since these are third-party applications and are external to the organization. - -Official Microsoft guidance for detecting and remediating this attack can be found [here](https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants). - -#### Possible investigation steps - -- From the Azure AD portal, Review the application that was granted permissions: - - Click on the `Review permissions` button on the `Permissions` blade of the application. - - An app should require only permissions related to the app's purpose. If that's not the case, the app might be risky. - - Apps that require high privileges or admin consent are more likely to be risky. -- Investigate the app and the publisher. The following characteristics can indicate suspicious apps: - - A low number of downloads. - - Low rating or score or bad comments. - - Apps with a suspicious publisher or website. - - Apps whose last update is not recent. This might indicate an app that is no longer supported. -- Export and examine the [Oauth app auditing](https://docs.microsoft.com/en-us/defender-cloud-apps/manage-app-permissions#oauth-app-auditing) to identify users affected. - -### False positive analysis - -- This mechanism can be used legitimately. Malicious applications abuse the same workflow used by legitimate apps. Thus, analysts must review each app consent to ensure that only desired apps are granted access. - -### Response and remediation - -- Initiate the incident response process based on the outcome of the triage. -- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: - - Identify the account role in the cloud environment. - - Assess the criticality of affected services and servers. - - Work with your IT team to identify and minimize the impact on users. - - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. - - Identify any regulatory or legal ramifications related to this activity. -- Disable the malicious application to stop user access and the application access to your data. -- Revoke the application Oauth consent grant. The `Remove-AzureADOAuth2PermissionGrant` cmdlet can be used to complete this task. -- Remove the service principal application role assignment. The `Remove-AzureADServiceAppRoleAssignment` cmdlet can be used to complete this task. -- Revoke the refresh token for all users assigned to the application. Azure provides a [playbook](https://github.com/Azure/Azure-Sentinel/tree/master/Playbooks/Revoke-AADSignInSessions) for this task. -- [Report](https://docs.microsoft.com/en-us/defender-cloud-apps/manage-app-permissions#send-feedback) the application as malicious to Microsoft. -- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. -- Investigate the potential for data compromise from the user's email and file sharing services. Activate your Data Loss incident response playbook. -- Disable the permission for a user to set consent permission on their behalf. - - Enable the [Admin consent request](https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/configure-admin-consent-workflow) feature. -- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). - -## Setup - -The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" -references = [ - "https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants?view=o365-worldwide", - "https://www.cloud-architekt.net/detection-and-mitigation-consent-grant-attacks-azuread/", - "https://docs.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth#how-to-detect-risky-oauth-apps", -] -risk_score = 47 -rule_id = "1c6a8c7a-5cb6-4a82-ba27-d5a5b8a40a38" -severity = "medium" -tags = [ - "Domain: Cloud", - "Data Source: Azure", - "Data Source: Microsoft 365", - "Use Case: Identity and Access Audit", - "Resources: Investigation Guide", - "Tactic: Initial Access", -] -timestamp_override = "event.ingested" -type = "query" - -query = ''' -event.dataset:(azure.activitylogs or azure.auditlogs or o365.audit) and - ( - azure.activitylogs.operation_name:"Consent to application" or - azure.auditlogs.operation_name:"Consent to application" or - event.action:"Consent to application." - ) and - event.outcome:(Success or success) -''' - - -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1566" -name = "Phishing" -reference = "https://attack.mitre.org/techniques/T1566/" -[[rule.threat.technique.subtechnique]] -id = "T1566.002" -name = "Spearphishing Link" -reference = "https://attack.mitre.org/techniques/T1566/002/" - - - -[rule.threat.tactic] -id = "TA0001" -name = "Initial Access" -reference = "https://attack.mitre.org/tactics/TA0001/" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1528" -name = "Steal Application Access Token" -reference = "https://attack.mitre.org/techniques/T1528/" - - -[rule.threat.tactic] -id = "TA0006" -name = "Credential Access" -reference = "https://attack.mitre.org/tactics/TA0006/" - diff --git a/rules/integrations/azure/initial_access_entra_illicit_consent_grant_via_registered_application.toml b/rules/integrations/azure/initial_access_entra_illicit_consent_grant_via_registered_application.toml new file mode 100644 index 00000000000..9ef4177c59b --- /dev/null +++ b/rules/integrations/azure/initial_access_entra_illicit_consent_grant_via_registered_application.toml @@ -0,0 +1,145 @@ +[metadata] +creation_date = "2020/09/01" +integration = ["azure"] +maturity = "production" +updated_date = "2025/03/24" + +[rule] +author = ["Elastic"] +description = """ +Identifies an illicit consent grant request on-behalf-of a registered Entra ID application. Adversaries may create and +register an application in Microsoft Entra ID for the purpose of requesting user consent to access resources. This is +accomplished by tricking a user into granting consent to the application, typically via a pre-made phishing URL. This +establishes an OAuth grant that allows the malicious client applocation to access resources on-behalf-of the user. +""" +from = "now-9m" +index = ["filebeat-*", "logs-azure*"] +language = "kuery" +license = "Elastic License v2" +name = "Microsoft Entra ID Illicit Consent Grant via Registered Application" +note = """## Triage and analysis + +### Investigating Microsoft Entra ID Illicit Consent Grant via Registered Application + +Adversaries may register a malicious application in Microsoft Entra ID and trick users into granting excessive permissions via OAuth consent. These applications can access sensitive data—such as mail, profiles, or files—on behalf of the user once consent is granted. This is commonly delivered via spearphishing links that prompt users to approve permissions for seemingly legitimate applications. + +This rule identifies a new consent grant event based on Azure audit logs where the application was granted access with potentially risky scopes, such as offline_access, Mail.Read, or User.Read, and may include admin consent or tenant-wide delegation. + +This is a New Terms rule that will only trigger if the user and client ID have not been seen doing this activity in the last 14 days. + +#### Possible investigation steps + +- Review `azure.auditlogs.properties.additional_details.value` to identify the AppId and User-Agent values to determine which application was granted access and how the request was initiated. Pivot on the AppId in the Azure portal under Enterprise Applications to investigate further. +- Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName` to identify the user who approved the application. Investigate their recent activity for signs of phishing, account compromise, or anomalous behavior during the timeframe of the consent. +- Review `azure.auditlogs.properties.initiated_by.user.ipAddress` to assess the geographic source of the consent action. Unexpected locations or IP ranges may indicate adversary-controlled infrastructure. +- Review `azure.auditlogs.properties.target_resources.display_name` to evaluate whether the application name is familiar, expected, or potentially spoofing a known service. +- Review `azure.auditlogs.properties.target_resources.modified_properties.display_name` to inspect key indicators of elevated privilege or risk, including: + - ConsentContext.IsAdminConsent to determine if the application was granted tenant-wide admin access. + - ConsentContext.OnBehalfOfAll to identify whether the app was granted permissions on behalf of all users in the tenant. + - ConsentAction.Permissions to evaluate the specific scopes and data access the application requested. + - ConsentAction.Reason to understand if Microsoft flagged the activity or if any reason was recorded by the platform. + - TargetId.ServicePrincipalNames to confirm the service principal associated with the granted permissions. +- Review `azure.tenant_id` to confirm the activity originated from your tenant and is not related to a cross-tenant application. +- Review `@timestamp` and `azure.auditlogs.properties.correlation_id` to pivot into related sign-in, token usage, or application activity for further context. + +### False positive analysis + +- Some applications may request high-privilege scopes for legitimate purposes. Validate whether the application is verified, developed by Microsoft, or approved internally by your organization. +- Review publisher verification, app ownership, and scope alignment with the intended business use case. + +### Response and remediation + +- Revoke the application’s OAuth grant using Graph API or PowerShell. Use the Remove-AzureADOAuth2PermissionGrant cmdlet. +- Remove the associated service principal from Azure AD. +- Reset credentials or revoke tokens for affected users. +- Block the application via Conditional Access or Defender for Cloud Apps policies. +- Enable the Admin Consent Workflow in Azure AD to prevent unsanctioned user approvals in the future. +- Report any malicious applications to Microsoft to protect other tenants. +""" +references = [ + "https://www.wiz.io/blog/midnight-blizzard-microsoft-breach-analysis-and-best-practices", + "https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants?view=o365-worldwide", + "https://www.cloud-architekt.net/detection-and-mitigation-consent-grant-attacks-azuread/", + "https://docs.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth#how-to-detect-risky-oauth-apps", +] +risk_score = 47 +rule_id = "1c6a8c7a-5cb6-4a82-ba27-d5a5b8a40a38" +severity = "medium" +tags = [ + "Domain: Cloud", + "Data Source: Azure", + "Data Source: Microsoft Entra ID", + "Data Source: Microsoft Entra ID Audit Logs", + "Use Case: Identity and Access Audit", + "Resources: Investigation Guide", + "Tactic: Initial Access", + "Tactic: Credential Access", +] +timestamp_override = "event.ingested" +type = "new_terms" + +query = ''' +event.dataset: "azure.auditlogs" and + ( + azure.auditlogs.operation_name:"Consent to application" + or event.action:"Consent to application" + ) + and event.outcome: "success" + and azure.auditlogs.properties.additional_details.key: "AppId" +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1566" +name = "Phishing" +reference = "https://attack.mitre.org/techniques/T1566/" +[[rule.threat.technique.subtechnique]] +id = "T1566.002" +name = "Spearphishing Link" +reference = "https://attack.mitre.org/techniques/T1566/002/" + + + +[rule.threat.tactic] +id = "TA0001" +name = "Initial Access" +reference = "https://attack.mitre.org/tactics/TA0001/" +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1528" +name = "Steal Application Access Token" +reference = "https://attack.mitre.org/techniques/T1528/" + + +[rule.threat.tactic] +id = "TA0006" +name = "Credential Access" +reference = "https://attack.mitre.org/tactics/TA0006/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "event.action", + "event.outcome", + "azure.auditlogs.properties.initiated_by.user.userPrincipalName", + "azure.auditlogs.properties.initiated_by.user.ipAddress", + "azure.auditlogs.properties.additional_details.value", + "azure.tenant_id", + "cloud.region", + "azure.auditlogs.properties.target_resources.0.display_name" +] + +[rule.new_terms] +field = "new_terms_fields" +value = [ + "azure.auditlogs.properties.initiated_by.user.userPrincipalName", + "azure.auditlogs.properties.additional_details.value", +] +[[rule.new_terms.history_window_start]] +field = "history_window_start" +value = "now-14d" + + diff --git a/rules/integrations/o365/initial_access_microsoft_365_illicit_consent_grant_via_registered_application.toml b/rules/integrations/o365/initial_access_microsoft_365_illicit_consent_grant_via_registered_application.toml new file mode 100644 index 00000000000..e18f124d09c --- /dev/null +++ b/rules/integrations/o365/initial_access_microsoft_365_illicit_consent_grant_via_registered_application.toml @@ -0,0 +1,154 @@ +[metadata] +creation_date = "2025/03/24" +integration = ["o365"] +maturity = "production" +updated_date = "2025/03/24" + +[rule] +author = ["Elastic"] +description = """ +Identifies an Microsoft 365 illicit consent grant request on-behalf-of a registered Entra ID application. Adversaries +may create and register an application in Microsoft Entra ID for the purpose of requesting user consent to access +resources in Microsoft 365. This is accomplished by tricking a user into granting consent to the application, typically +via a pre-made phishing URL. This establishes an OAuth grant that allows the malicious client applocation to access +resources in Microsoft 365 on-behalf-of the user. +""" +from = "now-9m" +index = ["filebeat-*", "logs-o365**"] +language = "kuery" +license = "Elastic License v2" +name = "Microsoft 365 Illicit Consent Grant via Registered Application" +note = """## Triage and analysis + +### Investigating Microsoft 365 Illicit Consent Grant via Registered Application + +Adversaries may register a malicious application in Microsoft Entra ID and trick users into granting excessive permissions via OAuth consent. These apps can access sensitive Microsoft 365 data—such as mail, profiles, and files—on behalf of the user once consent is granted. This activity is often initiated through spearphishing campaigns that direct the user to a pre-crafted OAuth consent URL. + +This rule identifies a new consent grant to an application using Microsoft 365 audit logs. Additionally, this is a New Terms rule that will only trigger if the user and client ID have not been seen doing this activity in the last 14 days. + +#### Possible investigation steps + +- **Review the app in Entra ID**: + - Go to **Enterprise Applications** in the Azure portal. + - Search for the `AppId` or name from `o365.audit.ObjectId`. + - Review granted API permissions and whether admin consent was required. + - Check the `Publisher` and `Verified` status. + +- **Assess the user who granted consent**: + - Investigate `o365.audit.UserId` (e.g., `terrance.dejesus@...`) for signs of phishing or account compromise. + - Check if the user was targeted in recent phishing simulations or campaigns. + - Review the user’s sign-in logs for suspicious geolocation, IP, or device changes. + +- **Determine scope and risk**: + - Use the `ConsentContext_IsAdminConsent` and `ConsentContext_OnBehalfOfAll` flags to assess privilege level. + - If `offline_access` or `Mail.Read` was granted, consider potential data exposure. + - Cross-reference affected `Target` objects with known business-critical assets or data owners. + +- **Correlate additional telemetry**: + - Review logs from Defender for Cloud Apps (MCAS), Microsoft Purview, or other DLP tooling for unusual access patterns. + - Search for `AppId` across your tenant to determine how widely it's used. + +### False positive analysis + +- Not all consent grants are malicious. Verify if the app is business-approved, listed in your app catalog, or commonly used by users in that role or department. +- Consent reasons like `WindowsAzureActiveDirectoryIntegratedApp` could relate to integrated services, though these still require verification. + +### Response and remediation + +- **If the app is confirmed malicious**: + - Revoke OAuth consent using the [Microsoft Graph API](https://learn.microsoft.com/en-us/graph/api/oauth2permissiongrant-delete). + - Remove any related service principals from Entra ID. + - Block the app via the Conditional Access "Grant" control or Defender for Cloud Apps policies. + - Revoke refresh tokens and require reauthentication for affected users. + - Notify end-users and IT of the potential exposure. + - Activate your phishing or OAuth abuse response playbook. + +- **Prevent future misuse**: + - Enable the [Admin consent workflow](https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/configure-admin-consent-workflow) to restrict user-granted consent. + - Audit and reduce overprivileged applications in your environment. + - Consider using Defender for Cloud Apps OAuth app governance. + +""" +references = [ + "https://www.wiz.io/blog/midnight-blizzard-microsoft-breach-analysis-and-best-practices", + "https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants?view=o365-worldwide", + "https://www.cloud-architekt.net/detection-and-mitigation-consent-grant-attacks-azuread/", + "https://docs.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth#how-to-detect-risky-oauth-apps", + "https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-schema", +] +risk_score = 47 +rule_id = "0c3c80de-08c2-11f0-bd11-f661ea17fbcc" +severity = "medium" +tags = [ + "Domain: Cloud", + "Data Source: Microsoft 365", + "Data Source: Microsoft 365 Audit Logs", + "Use Case: Identity and Access Audit", + "Resources: Investigation Guide", + "Tactic: Initial Access", + "Tactic: Credential Access", +] +timestamp_override = "event.ingested" +type = "new_terms" + +query = ''' +event.dataset: "o365.audit" + and o365.audit.Actor.Type: 5 + and event.action: "Consent to application." + and event.outcome: "success" + and o365.audit.Target.Type: (0 or 2 or 3 or 9 or 10) +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1566" +name = "Phishing" +reference = "https://attack.mitre.org/techniques/T1566/" +[[rule.threat.technique.subtechnique]] +id = "T1566.002" +name = "Spearphishing Link" +reference = "https://attack.mitre.org/techniques/T1566/002/" + + + +[rule.threat.tactic] +id = "TA0001" +name = "Initial Access" +reference = "https://attack.mitre.org/tactics/TA0001/" +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1528" +name = "Steal Application Access Token" +reference = "https://attack.mitre.org/techniques/T1528/" + + +[rule.threat.tactic] +id = "TA0006" +name = "Credential Access" +reference = "https://attack.mitre.org/tactics/TA0006/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "event.action", + "event.outcome", + "o365.audit.UserId", + "o365.audit.ObjectId", + "o365.audit.Actor.Type", + "o365.audit.Target.Type", + "o365.audit.ModifiedProperties.ConsentAction_Reason.NewValue", + "o365.audit.ExtendedProperties.additionalDetails", + "cloud.region" +] + +[rule.new_terms] +field = "new_terms_fields" +value = ["o365.audit.UserId", "o365.audit.ObjectId"] +[[rule.new_terms.history_window_start]] +field = "history_window_start" +value = "now-14d" + +