From 51a3b86c99aa8348527b3461a1a98956a05f7fbd Mon Sep 17 00:00:00 2001 From: pyth0n1c Date: Wed, 8 Nov 2023 14:29:05 -0800 Subject: [PATCH] Fix observable issues, unicode characters, and newline issues in detections. --- .../azure_ad_block_user_consent_for_risky_apps_disabled.yml | 4 ++-- detections/cloud/azure_ad_device_code_authentication.yml | 6 +++--- detections/cloud/azure_ad_new_mfa_method_registered.yml | 2 +- .../azure_ad_oauth_application_consent_granted_by_user.yml | 2 +- .../cloud/azure_ad_tenant_wide_admin_consent_granted.yml | 2 +- .../azure_ad_user_consent_blocked_for_risky_application.yml | 2 +- 6 files changed, 9 insertions(+), 9 deletions(-) diff --git a/detections/cloud/azure_ad_block_user_consent_for_risky_apps_disabled.yml b/detections/cloud/azure_ad_block_user_consent_for_risky_apps_disabled.yml index 51dd588b31..3582f54f6a 100644 --- a/detections/cloud/azure_ad_block_user_consent_for_risky_apps_disabled.yml +++ b/detections/cloud/azure_ad_block_user_consent_for_risky_apps_disabled.yml @@ -7,7 +7,7 @@ status: production type: TTP data_source: [] description: This analytic detects when the risk-based step-up consent security setting in Azure AD is disabled. This setting, when enabled, prevents regular users from granting consent to potentially malicious OAuth applications, requiring an administrative step-up for consent instead. Disabling this feature could expose the organization to OAuth phishing threats.The detection operates by monitoring Azure Active Directory logs for events where the "Update authorization policy" operation is performed. It specifically looks for changes to the "AllowUserConsentForRiskyApps" setting, identifying instances where this setting is switched to "true," effectively disabling the risk-based step-up consent. Monitoring for changes to critical security settings like the "risk-based step-up consent" is vital for maintaining the integrity of an organization's security posture. Disabling this feature can make the environment more susceptible to OAuth phishing attacks, where attackers trick users into granting permissions to malicious applications. Identifying when this setting is disabled can help blue teams to quickly respond, investigate, and potentially uncover targeted phishing campaigns against their users. If an attacker successfully disables the "risk-based step-up consent" and subsequently launches an OAuth phishing campaign, they could gain unauthorized access to user data and other sensitive information within the M365 environment. This could lead to data breaches, unauthorized access to emails, and potentially further compromise within the organization -search: > +search: >- `azure_monitor_aad` operationName="Update authorization policy" | rename properties.* as * | eval index_number = if(mvfind('targetResources{}.modifiedProperties{}.displayName', "AllowUserConsentForRiskyApps") >= 0, mvfind('targetResources{}.modifiedProperties{}.displayName', "AllowUserConsentForRiskyApps"), -1) @@ -21,7 +21,7 @@ search: > how_to_implement: You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category. -known_false_positives: Legitimate changes to the 'risk-based step-up consent' setting by administrators, perhaps as part of a policy update or security assessment, may trigger this alert, necessitating verification of the change’s intent and authorization +known_false_positives: Legitimate changes to the 'risk-based step-up consent' setting by administrators, perhaps as part of a policy update or security assessment, may trigger this alert, necessitating verification of the change's intent and authorization references: - https://attack.mitre.org/techniques/T1562/ - https://goodworkaround.com/2020/10/19/a-look-behind-the-azure-ad-permission-classifications-preview/ diff --git a/detections/cloud/azure_ad_device_code_authentication.yml b/detections/cloud/azure_ad_device_code_authentication.yml index 511d710f7e..dcb5c8b1a1 100644 --- a/detections/cloud/azure_ad_device_code_authentication.yml +++ b/detections/cloud/azure_ad_device_code_authentication.yml @@ -37,17 +37,17 @@ tags: asset_type: Azure AD confidence: 50 impact: 70 - message: Device code requested for $userPrincipalName$ from $ipAddress$ + message: Device code requested for $user$ from $src_ip$ mitre_attack_id: - T1528 - T1566 - T1566.002 observable: - - name: userPrincipalName + - name: user type: User role: - Victim - - name: ipAddress + - name: src_ip type: IP Address role: - Attacker diff --git a/detections/cloud/azure_ad_new_mfa_method_registered.yml b/detections/cloud/azure_ad_new_mfa_method_registered.yml index 2aaa87fb98..6ff1d2a24a 100644 --- a/detections/cloud/azure_ad_new_mfa_method_registered.yml +++ b/detections/cloud/azure_ad_new_mfa_method_registered.yml @@ -7,7 +7,7 @@ status: production type: TTP data_source: [] description: This analytic detects the registration of a new Multi-Factor Authentication (MFA) method associated with a user account within Azure Active Directory by monitoring Azure AD audit logs and configurations. While adding a new MFA method can be a routine and legitimate action, it can also be indicative of an attacker's attempt to maintain persistence on a compromised account. By registering a new MFA method, attackers can potentially bypass existing security measures, allowing them to authenticate using stolen credentials without raising alarms. Monitoring for such changes is crucial, especially if the addition is not preceded by a user request or if it deviates from typical user behavior. If an attacker successfully registers a new MFA method on a compromised account, they can solidify their access, making it harder for legitimate users to regain control. The attacker can then operate with the privileges of the compromised account, potentially accessing sensitive data, making unauthorized changes, or even escalating their privileges further. Immediate action would be required to verify the legitimacy of the MFA change and, if malicious, to remediate and secure the affected account. -search: > +search: >- `azure_monitor_aad` operationName="Update user" | rename properties.* as * | eval propertyName = mvindex('targetResources{}.modifiedProperties{}.displayName', 0) diff --git a/detections/cloud/azure_ad_oauth_application_consent_granted_by_user.yml b/detections/cloud/azure_ad_oauth_application_consent_granted_by_user.yml index 7ec45152b2..84bd5c2b0b 100644 --- a/detections/cloud/azure_ad_oauth_application_consent_granted_by_user.yml +++ b/detections/cloud/azure_ad_oauth_application_consent_granted_by_user.yml @@ -7,7 +7,7 @@ status: production type: TTP data_source: [] description: This analytic detects when a user in an Azure AD environment grants consent to an OAuth application, capturing any consent granted regardless of the specific permissions requested. Utilizing Azure AD audit logs, it focuses on events related to OAuth application consents, alerting security teams to instances where users actively grant consent to applications. This monitoring is crucial as it highlights potential risks associated with third-party applications gaining access to organizational data, a tactic often exploited by malicious actors to gain unauthorized access. A true positive from this analytic necessitates immediate investigation to validate the application's legitimacy, review the granted permissions, and assess potential risks, helping to prevent unauthorized access and protect sensitive data and resources. While false positives may occur with legitimate application integrations, ensuring alignment with organizational policies and security best practices is paramount. -search: > +search: >- `azure_monitor_aad` operationName="Consent to application" properties.result=success | rename properties.* as * | eval permissions_index = if(mvfind('targetResources{}.modifiedProperties{}.displayName', "ConsentAction.Permissions") >= 0, mvfind('targetResources{}.modifiedProperties{}.displayName', "ConsentAction.Permissions"), -1) diff --git a/detections/cloud/azure_ad_tenant_wide_admin_consent_granted.yml b/detections/cloud/azure_ad_tenant_wide_admin_consent_granted.yml index 5d86bf4ab4..0f621ddf20 100644 --- a/detections/cloud/azure_ad_tenant_wide_admin_consent_granted.yml +++ b/detections/cloud/azure_ad_tenant_wide_admin_consent_granted.yml @@ -7,7 +7,7 @@ status: production type: TTP data_source: [] description: The following analytic identifies instances where admin consent is granted to an application within an Azure AD tenant. It leverages Azure AD audit logs, specifically events related to the admin consent action within the ApplicationManagement category. The admin consent action allows applications to access data across the entire tenant, potentially encompassing a vast amount of organizational data. Given its broad scope and the sensitivity of some permissions that can only be granted via admin consent, it's crucial to monitor this action. Unauthorized or inadvertent granting of admin consent can lead to significant security risks, including data breaches, unauthorized data access, and potential compliance violations. If an attacker successfully tricks an administrator into granting admin consent to a malicious or compromised application, they can gain extensive and persistent access to organizational data. This can lead to data exfiltration, espionage, further malicious activities within the tenant, and potential breaches of compliance regulations -search: > +search: >- `azure_monitor_aad` operationName="Consent to application" | eval new_field=mvindex('properties.targetResources{}.modifiedProperties{}.newValue', 4) | rename properties.* as * diff --git a/detections/cloud/azure_ad_user_consent_blocked_for_risky_application.yml b/detections/cloud/azure_ad_user_consent_blocked_for_risky_application.yml index 5673b5333b..8d63e5c709 100644 --- a/detections/cloud/azure_ad_user_consent_blocked_for_risky_application.yml +++ b/detections/cloud/azure_ad_user_consent_blocked_for_risky_application.yml @@ -7,7 +7,7 @@ status: production type: TTP data_source: [] description: The following analytic identifies instances where Azure AD has blocked a user's attempt to grant consent to an application deemed risky or potentially malicious. This suggests that the application has exhibited behaviors or characteristics that are commonly associated with malicious intent or poses a security risk. This detection leverages the Azure AD audit logs, specifically focusing on events related to user consent actions and system-driven blocks. By filtering for blocked consent actions associated with applications, the analytic highlights instances where Azure's built-in security measures have intervened. Applications that are flagged and blocked by Azure typically exhibit suspicious characteristics or behaviors. Monitoring for these blocked consent attempts helps security teams identify potential threats early on and can provide insights into users who might be targeted or susceptible to such risky applications. It's an essential layer of defense in ensuring that malicious or risky applications don't gain access to organizational data. If the detection is a true positive, it indicates that the built-in security measures of O365 successfully prevented a potentially harmful application from gaining access. However, the attempt itself suggests that either a user might be targeted or that there's a presence of malicious applications trying to infiltrate the organization. Immediate investigation is required to understand the context of the block and to take further preventive measures. -search: > +search: >- `azure_monitor_aad` operationName="Consent to application" properties.result=failure | rename properties.* as * | eval reason_index = if(mvfind('targetResources{}.modifiedProperties{}.displayName', "ConsentAction.Reason") >= 0, mvfind('targetResources{}.modifiedProperties{}.displayName', "ConsentAction.Reason"), -1)