From 4e10322ea8975e1c7314f178d276cecc691dea35 Mon Sep 17 00:00:00 2001 From: mvelazco Date: Thu, 3 Aug 2023 18:56:34 -0400 Subject: [PATCH 01/33] adding new detection --- .../azure_ad_device_code_authentication.yml | 47 +++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 detections/cloud/azure_ad_device_code_authentication.yml diff --git a/detections/cloud/azure_ad_device_code_authentication.yml b/detections/cloud/azure_ad_device_code_authentication.yml new file mode 100644 index 0000000000..3150c759f4 --- /dev/null +++ b/detections/cloud/azure_ad_device_code_authentication.yml @@ -0,0 +1,47 @@ +name: Azure AD Device Code Authentication +id: d68d8732-6f7e-4ee5-a6eb-737f2b990b91 +version: 1 +date: '2023-08-03' +author: Mauricio Velazco, Splunk +status: production +type: TTP +data_source: +- UPDATE_DATA_SOURCE +description: UPDATE_DESCRIPTION +search: ' `azuread` properties.authenticationProtocol=deviceCode + | `azure_ad_device_code_authentication_filter`' +how_to_implement: UPDATE_HOW_TO_IMPLEMENT +known_false_positives: UPDATE_KNOWN_FALSE_POSITIVES +references: +- https://attack.mitre.org/techniques/T1528 +- https://github.com/rvrsh3ll/TokenTactics +- https://embracethered.com/blog/posts/2022/device-code-phishing/ +- https://0xboku.com/2021/07/12/ArtOfDeviceCodePhish.html +tags: + analytic_story: + - Azure Active Directory Account Takeover + asset_type: Azure AD + confidence: 50 + impact: 70 + message: UPDATE message + mitre_attack_id: + - T1528 + observable: + - name: userPrincipalName + type: User + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + risk_score: 35 + required_fields: + - UPDATE_required_fields + security_domain: identity +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1528/device_code_authentication/azure-audit.log + source: mscs:azure:eventhub + sourcetype: mscs:azure:eventhub From 62d4818c2c0091dd238aa629edbc2f0165f88cee Mon Sep 17 00:00:00 2001 From: Gowthamaraj rajendran Date: Tue, 8 Aug 2023 14:24:14 -0700 Subject: [PATCH 02/33] update detections/cloud/azure_ad_device_code_authentication.yml --- .../azure_ad_device_code_authentication.yml | 43 +++++++++++++++---- 1 file changed, 35 insertions(+), 8 deletions(-) diff --git a/detections/cloud/azure_ad_device_code_authentication.yml b/detections/cloud/azure_ad_device_code_authentication.yml index 3150c759f4..638c7df00f 100644 --- a/detections/cloud/azure_ad_device_code_authentication.yml +++ b/detections/cloud/azure_ad_device_code_authentication.yml @@ -5,39 +5,66 @@ date: '2023-08-03' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: -- UPDATE_DATA_SOURCE -description: UPDATE_DESCRIPTION -search: ' `azuread` properties.authenticationProtocol=deviceCode +data_source: [] +description: The following analytic identifies the execution of the Azure Device Code Phishing attack, + which can lead to Azure Account Take-Over (ATO). The detection leverages Azure AD logs specifically + focusing on authentication requests to identify the attack. This technique involves creating malicious + infrastructure, bypassing Multi-Factor Authentication (MFA), and bypassing Conditional Access Policies (CAPs). + The attack aims to compromise users by sending them phishing emails from attacker-controlled domains and trick + the victims into performing OAuth 2.0 device authentication. A successful execution of this attack can result + in adversaries gaining unauthorized access to Azure AD, Exchange mailboxes, and the target's Outlook Web Application (OWA). + This attack technique was detailed by security researchers including Bobby Cooke, Stephan Borosh, and others. + It's crucial for organizations to be aware of this threat, as it can lead to unauthorized access and potential data breaches. +search: '`azuread` category=SignInLogs "properties.authenticationProtocol"=deviceCode + | rename properties.* as * | stats values(userPrincipalName) by _time, ipAddress, + status.additionalDetails, appDisplayName, userAgent | `azure_ad_device_code_authentication_filter`' -how_to_implement: UPDATE_HOW_TO_IMPLEMENT -known_false_positives: UPDATE_KNOWN_FALSE_POSITIVES +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. + Specifically, this analytic leverages the AuditLogs log category. +known_false_positives: In most organizations, Code Based Authentication will be used + rarely. Filter as needed. references: - https://attack.mitre.org/techniques/T1528 - https://github.com/rvrsh3ll/TokenTactics - https://embracethered.com/blog/posts/2022/device-code-phishing/ - https://0xboku.com/2021/07/12/ArtOfDeviceCodePhish.html +- https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-device-code tags: analytic_story: - Azure Active Directory Account Takeover asset_type: Azure AD confidence: 50 impact: 70 - message: UPDATE message + message: Device code requested for $userPrincipalName$ from $ipAddress$ mitre_attack_id: - T1528 + - T1566 + - T1566.002 observable: - name: userPrincipalName type: User role: - Victim + - name: ipAddress + type: IP Address + role: + - Attacker product: - Splunk Enterprise - Splunk Enterprise Security - Splunk Cloud risk_score: 35 required_fields: - - UPDATE_required_fields + - _time + - body.category + - body.properties.authenticationProtocol + - body.properties.userPrincipalName + - body.properties.ipAddress + - body.properties.status.additionalDetails + - body.properties.appDisplayName + - body.properties.userAgent security_domain: identity tests: - name: True Positive Test From a19575a09be581025b2e1e2bbfe799c723425328 Mon Sep 17 00:00:00 2001 From: Gowthamaraj rajendran Date: Wed, 9 Aug 2023 10:58:05 -0700 Subject: [PATCH 03/33] Edit SPL --- detections/cloud/azure_ad_device_code_authentication.yml | 2 -- 1 file changed, 2 deletions(-) diff --git a/detections/cloud/azure_ad_device_code_authentication.yml b/detections/cloud/azure_ad_device_code_authentication.yml index 638c7df00f..8e490a0be7 100644 --- a/detections/cloud/azure_ad_device_code_authentication.yml +++ b/detections/cloud/azure_ad_device_code_authentication.yml @@ -16,8 +16,6 @@ description: The following analytic identifies the execution of the Azure Device This attack technique was detailed by security researchers including Bobby Cooke, Stephan Borosh, and others. It's crucial for organizations to be aware of this threat, as it can lead to unauthorized access and potential data breaches. search: '`azuread` category=SignInLogs "properties.authenticationProtocol"=deviceCode - | rename properties.* as * | stats values(userPrincipalName) by _time, ipAddress, - status.additionalDetails, appDisplayName, userAgent | `azure_ad_device_code_authentication_filter`' 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). From 92b7f397150e25f011cdc159481374ca1ae3cbf8 Mon Sep 17 00:00:00 2001 From: Gowthamaraj rajendran Date: Wed, 9 Aug 2023 11:40:35 -0700 Subject: [PATCH 04/33] Update SPL --- detections/cloud/azure_ad_device_code_authentication.yml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/detections/cloud/azure_ad_device_code_authentication.yml b/detections/cloud/azure_ad_device_code_authentication.yml index 8e490a0be7..a5958f962b 100644 --- a/detections/cloud/azure_ad_device_code_authentication.yml +++ b/detections/cloud/azure_ad_device_code_authentication.yml @@ -16,6 +16,8 @@ description: The following analytic identifies the execution of the Azure Device This attack technique was detailed by security researchers including Bobby Cooke, Stephan Borosh, and others. It's crucial for organizations to be aware of this threat, as it can lead to unauthorized access and potential data breaches. search: '`azuread` category=SignInLogs "properties.authenticationProtocol"=deviceCode + | rename properties.* as * + | stats values(userPrincipalName) by _time, ipAddress, appDisplayName, userAgent | `azure_ad_device_code_authentication_filter`' 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). @@ -60,7 +62,6 @@ tags: - body.properties.authenticationProtocol - body.properties.userPrincipalName - body.properties.ipAddress - - body.properties.status.additionalDetails - body.properties.appDisplayName - body.properties.userAgent security_domain: identity From 881722c1581d4ef605afad2d21df27f7ec1b1eb7 Mon Sep 17 00:00:00 2001 From: Gowthamaraj rajendran Date: Wed, 9 Aug 2023 12:02:16 -0700 Subject: [PATCH 05/33] Update required fields --- .../cloud/azure_ad_device_code_authentication.yml | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/detections/cloud/azure_ad_device_code_authentication.yml b/detections/cloud/azure_ad_device_code_authentication.yml index a5958f962b..e0cec77df4 100644 --- a/detections/cloud/azure_ad_device_code_authentication.yml +++ b/detections/cloud/azure_ad_device_code_authentication.yml @@ -17,7 +17,7 @@ description: The following analytic identifies the execution of the Azure Device It's crucial for organizations to be aware of this threat, as it can lead to unauthorized access and potential data breaches. search: '`azuread` category=SignInLogs "properties.authenticationProtocol"=deviceCode | rename properties.* as * - | stats values(userPrincipalName) by _time, ipAddress, appDisplayName, userAgent + | stats values(userPrincipalName) by _time, ipAddress, status.additionalDetails, appDisplayName, userAgent | `azure_ad_device_code_authentication_filter`' 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). @@ -58,12 +58,13 @@ tags: risk_score: 35 required_fields: - _time - - body.category - - body.properties.authenticationProtocol - - body.properties.userPrincipalName - - body.properties.ipAddress - - body.properties.appDisplayName - - body.properties.userAgent + - category + - properties.authenticationProtocol + - properties.userPrincipalName + - properties.ipAddress + - properties.status.additionalDetails + - properties.appDisplayName + - properties.userAgent security_domain: identity tests: - name: True Positive Test From b0b9f93a07b81c41be19a9a1e301675253a477e9 Mon Sep 17 00:00:00 2001 From: Gowthamaraj rajendran Date: Wed, 9 Aug 2023 12:22:53 -0700 Subject: [PATCH 06/33] Update SPL --- detections/cloud/azure_ad_device_code_authentication.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/detections/cloud/azure_ad_device_code_authentication.yml b/detections/cloud/azure_ad_device_code_authentication.yml index e0cec77df4..702f5f214b 100644 --- a/detections/cloud/azure_ad_device_code_authentication.yml +++ b/detections/cloud/azure_ad_device_code_authentication.yml @@ -17,7 +17,7 @@ description: The following analytic identifies the execution of the Azure Device It's crucial for organizations to be aware of this threat, as it can lead to unauthorized access and potential data breaches. search: '`azuread` category=SignInLogs "properties.authenticationProtocol"=deviceCode | rename properties.* as * - | stats values(userPrincipalName) by _time, ipAddress, status.additionalDetails, appDisplayName, userAgent + | stats values(userPrincipalName) by _time, ipAddress, appDisplayName, userAgent | `azure_ad_device_code_authentication_filter`' 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). From 00e0bef72bdcdd37439d70553f9da04eeb2e1f1b Mon Sep 17 00:00:00 2001 From: Gowthamaraj rajendran Date: Thu, 10 Aug 2023 11:02:54 -0700 Subject: [PATCH 07/33] Add info --- detections/cloud/azure_ad_device_code_authentication.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/detections/cloud/azure_ad_device_code_authentication.yml b/detections/cloud/azure_ad_device_code_authentication.yml index 702f5f214b..9b380c0bfa 100644 --- a/detections/cloud/azure_ad_device_code_authentication.yml +++ b/detections/cloud/azure_ad_device_code_authentication.yml @@ -2,7 +2,7 @@ name: Azure AD Device Code Authentication id: d68d8732-6f7e-4ee5-a6eb-737f2b990b91 version: 1 date: '2023-08-03' -author: Mauricio Velazco, Splunk +author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk status: production type: TTP data_source: [] From 5497c4ba03a24ba5d15b7417426a68245726d0f4 Mon Sep 17 00:00:00 2001 From: mvelazco Date: Thu, 14 Sep 2023 13:11:33 -0400 Subject: [PATCH 08/33] new detection --- ...e_ad_tenant_wide_admin_consent_granted.yml | 63 +++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 detections/cloud/azure_ad_tenant_wide_admin_consent_granted.yml diff --git a/detections/cloud/azure_ad_tenant_wide_admin_consent_granted.yml b/detections/cloud/azure_ad_tenant_wide_admin_consent_granted.yml new file mode 100644 index 0000000000..1cd7278e8b --- /dev/null +++ b/detections/cloud/azure_ad_tenant_wide_admin_consent_granted.yml @@ -0,0 +1,63 @@ +name: Azure AD Tenant Wide Admin Consent Granted +id: dc02c0ee-6ac0-4c7f-87ba-8ce43a4e4418 +version: 1 +date: '2023-09-14' +author: Mauricio Velazco, Splunk +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: > + `azuread` operationName="Consent to application" + | eval new_field=mvindex('properties.targetResources{}.modifiedProperties{}.newValue', 4) + | rex field=new_field "ConsentType: (?[^\,]+)" + | stats max(_time) as _time by operationName, properties.initiatedBy.user.userPrincipalName, properties.targetResources{}.displayName, properties.targetResources{}.id, ConsentType + | `security_content_ctime(lastTime)` + | `azure_ad_tenant_wide_admin_consent_granted_filter` +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. + Specifically, this analytic leverages the AuditLogs log category. +known_false_positives: Legitimate applications may be granted tenant wide consent, filter as needed. +references: +- https://attack.mitre.org/techniques/T1098/003/ +- https://www.mandiant.com/resources/blog/remediation-and-hardening-strategies-for-microsoft-365-to-defend-against-unc2452 +- https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-app-consent +- https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/grant-admin-consent?pivots=portal +- https://microsoft.github.io/Azure-Threat-Research-Matrix/Persistence/AZT501/AZT501-2/ +tags: + analytic_story: + - UPDATE_STORY_NAME + asset_type: Azure AD + atomic_guid: + - UPDATE atomic_guid + confidence: 50 + impact: 90 + message: UPDATE message + mitre_attack_id: + - T1098 + - T1098.003 + observable: + - name: properties.initiatedBy.user.userPrincipalName + type: User + role: + - Attacker + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + risk_score: 45 + required_fields: + - _time + - operationName + - properties.targetResources{}.modifiedProperties{}.newValue + - properties.initiatedBy.user.userPrincipalName + - properties.targetResources{}.displayName + - properties.targetResources{}.id + security_domain: identity +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_admin_consent/azure_ad_admin_consent.log + source: mscs:azure:eventhub + sourcetype: mscs:azure:eventhub \ No newline at end of file From d68a917dcb0084ecee9a12ba400ee0422fe99378 Mon Sep 17 00:00:00 2001 From: mvelazco Date: Wed, 25 Oct 2023 16:34:22 -0400 Subject: [PATCH 09/33] adding new detection --- ...ds_and_useragents_authentication_spike.yml | 47 +++++++++++++++++++ macros/azuread.yml | 2 +- 2 files changed, 48 insertions(+), 1 deletion(-) create mode 100644 detections/cloud/azure_ad_multiple_appids_and_useragents_authentication_spike.yml diff --git a/detections/cloud/azure_ad_multiple_appids_and_useragents_authentication_spike.yml b/detections/cloud/azure_ad_multiple_appids_and_useragents_authentication_spike.yml new file mode 100644 index 0000000000..40e8cdcfea --- /dev/null +++ b/detections/cloud/azure_ad_multiple_appids_and_useragents_authentication_spike.yml @@ -0,0 +1,47 @@ +name: Azure AD Multiple AppIDs and UserAgents Authentication Spike +id: 5d8bb1f0-f65a-4b4e-af2e-fcdb88276314 +version: 1 +date: '2023-10-25' +author: Mauricio Velazco, Splunk +status: production +type: Anomaly +data_source: +- UPDATE_DATA_SOURCE +description: UPDATE_DESCRIPTION +search: ' `azuread` category=SignInLogs operationName="Sign-in activity" (properties.authenticationRequirement="multiFactorAuthentication" AND properties.status.additionalDetails="MFA required in Azure AD") OR (properties.authenticationRequirement=singleFactorAuthentication AND "properties.authenticationDetails{}.succeeded"=true) + | bucket span=5m _time + | stats dc(_raw) as failed_attempts dc(properties.appId) as unique_app_ids dc(properties.userAgent) as unique_user_agents values(properties.appDisplayName) values(properties.deviceDetail.operatingSystem) by _time user src_ip + | where failed_attempts > 5 and unique_app_ids > 2 and unique_user_agents > 5 + | `azure_ad_multiple_appids_and_useragents_authentication_spike_filter`' +how_to_implement: UPDATE_HOW_TO_IMPLEMENT +known_false_positives: UPDATE_KNOWN_FALSE_POSITIVES +references: +- REFERENCE +tags: + analytic_story: + - Azure Active Directory Account Takeover + asset_type: UPDATE asset_type + confidence: 80 + impact: 60 + message: UPDATE message + mitre_attack_id: + - T1078 + observable: + - name: user + type: User + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + risk_score: 48 + required_fields: + - UPDATE_required_fields + security_domain: identity +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/azure_ad_multiple_appids_and_useragents_auth/azure_ad_multiple_appids_and_useragents_auth.log + source: Azure AD + sourcetype: azure:monitor:aad diff --git a/macros/azuread.yml b/macros/azuread.yml index bff933179e..c198da33b1 100644 --- a/macros/azuread.yml +++ b/macros/azuread.yml @@ -1,4 +1,4 @@ -definition: sourcetype=mscs:azure:eventhub +definition: sourcetype=mscs:azure:eventhub or sourcetype=azure:monitor:aad description: customer specific splunk configurations(eg- index, source, sourcetype). Replace the macro definition with configurations for your Splunk Environmnent. name: azuread From 706f713b75ed1ed6ab0da519eaace6d6e4fe23c0 Mon Sep 17 00:00:00 2001 From: mvelazco Date: Wed, 25 Oct 2023 16:57:10 -0400 Subject: [PATCH 10/33] update macro --- macros/azuread.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/macros/azuread.yml b/macros/azuread.yml index c198da33b1..60a2ab78d3 100644 --- a/macros/azuread.yml +++ b/macros/azuread.yml @@ -1,4 +1,4 @@ -definition: sourcetype=mscs:azure:eventhub or sourcetype=azure:monitor:aad +definition: sourcetype=mscs:azure:eventhub OR sourcetype=azure:monitor:aad description: customer specific splunk configurations(eg- index, source, sourcetype). Replace the macro definition with configurations for your Splunk Environmnent. name: azuread From 92cf1599be868fae6a38f5fd063078428fab9044 Mon Sep 17 00:00:00 2001 From: mvelazco Date: Thu, 26 Oct 2023 13:07:45 -0400 Subject: [PATCH 11/33] updating detections --- .../azure_ad_device_code_authentication.yml | 18 +++++------ ...ds_and_useragents_authentication_spike.yml | 32 +++++++++++++------ ...e_ad_tenant_wide_admin_consent_granted.yml | 25 +++++++-------- 3 files changed, 43 insertions(+), 32 deletions(-) diff --git a/detections/cloud/azure_ad_device_code_authentication.yml b/detections/cloud/azure_ad_device_code_authentication.yml index 9b380c0bfa..589b918f41 100644 --- a/detections/cloud/azure_ad_device_code_authentication.yml +++ b/detections/cloud/azure_ad_device_code_authentication.yml @@ -17,14 +17,14 @@ description: The following analytic identifies the execution of the Azure Device It's crucial for organizations to be aware of this threat, as it can lead to unauthorized access and potential data breaches. search: '`azuread` category=SignInLogs "properties.authenticationProtocol"=deviceCode | rename properties.* as * - | stats values(userPrincipalName) by _time, ipAddress, appDisplayName, userAgent + | stats count min(_time) as firstTime max(_time) as lastTime by user src_ip, appDisplayName, userAgent + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` | `azure_ad_device_code_authentication_filter`' 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. - Specifically, this analytic leverages the AuditLogs log category. -known_false_positives: In most organizations, Code Based Authentication will be used - rarely. Filter as needed. + 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 SignInLogs log category. +known_false_positives: In most organizations, device code authentication will be used to access common Microsoft service but it may be legitimate for others. Filter as needed. references: - https://attack.mitre.org/techniques/T1528 - https://github.com/rvrsh3ll/TokenTactics @@ -59,8 +59,8 @@ tags: required_fields: - _time - category + - user - properties.authenticationProtocol - - properties.userPrincipalName - properties.ipAddress - properties.status.additionalDetails - properties.appDisplayName @@ -70,5 +70,5 @@ tests: - name: True Positive Test attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1528/device_code_authentication/azure-audit.log - source: mscs:azure:eventhub - sourcetype: mscs:azure:eventhub + source: Azure AD + sourcetype: azure:monitor:aad diff --git a/detections/cloud/azure_ad_multiple_appids_and_useragents_authentication_spike.yml b/detections/cloud/azure_ad_multiple_appids_and_useragents_authentication_spike.yml index 40e8cdcfea..0c74387e40 100644 --- a/detections/cloud/azure_ad_multiple_appids_and_useragents_authentication_spike.yml +++ b/detections/cloud/azure_ad_multiple_appids_and_useragents_authentication_spike.yml @@ -5,25 +5,30 @@ date: '2023-10-25' author: Mauricio Velazco, Splunk status: production type: Anomaly -data_source: -- UPDATE_DATA_SOURCE -description: UPDATE_DESCRIPTION +data_source: [] +description: This analytic is crafted to identify unusual and potentially malicious authentication activity within an Azure AD environment. It triggers when a single user account is involved in more than 8 authentication attempts, using 3 or more unique application IDs and more than 5 unique user agents within a short timeframe. This pattern is atypical for regular user behavior and may indicate an adversary’s attempt to probe the environment, testing for multi-factor authentication requirements across different applications and platforms. The detection is based on analysis of Azure AD audit logs, specifically focusing on authentication events. It employs statistical thresholds to highlight instances where the volume of authentication attempts and the diversity of application IDs and user agents associated with a single user account exceed normal parameters. Identifying this behavior is crucial as it provides an early indication of potential account compromise. Adversaries, once in possession of user credentials, often conduct reconnaissance to understand the security controls in place, including multi-factor authentication configurations. Tools like Invoke-MFASweep are commonly used for this purpose, automating the process of testing different user agents and application IDs to bypass MFA. By detecting these initial probing attempts, security teams can swiftly respond, potentially stopping an attack in its early stages and preventing further unauthorized access. This proactive stance is vital for maintaining the integrity of the organization’s security posture. If validated as a true positive, this detection points to a compromised account, signaling that an attacker is actively attempting to navigate security controls to maintain access and potentially escalate privileges. This could lead to further exploitation, lateral movement within the network, and eventual data exfiltration. Recognizing and responding to this early stage of an attack is vital for preventing substantial harm and safeguarding sensitive organizational data and systems. search: ' `azuread` category=SignInLogs operationName="Sign-in activity" (properties.authenticationRequirement="multiFactorAuthentication" AND properties.status.additionalDetails="MFA required in Azure AD") OR (properties.authenticationRequirement=singleFactorAuthentication AND "properties.authenticationDetails{}.succeeded"=true) | bucket span=5m _time - | stats dc(_raw) as failed_attempts dc(properties.appId) as unique_app_ids dc(properties.userAgent) as unique_user_agents values(properties.appDisplayName) values(properties.deviceDetail.operatingSystem) by _time user src_ip + | rename properties.* as * + | stats dc(_raw) as failed_attempts dc(appId) as unique_app_ids dc(userAgent) as unique_user_agents values(appDisplayName) values(deviceDetail.operatingSystem) by _time user src_ip | where failed_attempts > 5 and unique_app_ids > 2 and unique_user_agents > 5 | `azure_ad_multiple_appids_and_useragents_authentication_spike_filter`' -how_to_implement: UPDATE_HOW_TO_IMPLEMENT -known_false_positives: UPDATE_KNOWN_FALSE_POSITIVES +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 SignInLogs log category. +known_false_positives: Rapid authentication from the same user using more than 5 different user agents and 3 application IDs is highly unlikely under normal circumstances. However, there are potential scenarios that could lead to false positives. references: -- REFERENCE +- https://attack.mitre.org/techniques/T1078/ +- https://www.blackhillsinfosec.com/exploiting-mfa-inconsistencies-on-microsoft-services/ +- https://github.com/dafthack/MFASweep +- https://www.youtube.com/watch?v=SK1zgqaAZ2E tags: analytic_story: - Azure Active Directory Account Takeover - asset_type: UPDATE asset_type + asset_type: Azure AD Tenant confidence: 80 impact: 60 - message: UPDATE message + message: $user$ authenticated in a short periof of time with more than 5 different user agents across 3 or more unique application ids. mitre_attack_id: - T1078 observable: @@ -37,7 +42,14 @@ tags: - Splunk Cloud risk_score: 48 required_fields: - - UPDATE_required_fields + - _time + - category + - operationName + - properties.authenticationRequirement + - properties.status.additionalDetails + - properties.authenticationDetails{}.succeeded + - properties.userAgent + - properties.appDisplayName security_domain: identity tests: - name: True Positive Test 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 1cd7278e8b..674a6fea81 100644 --- a/detections/cloud/azure_ad_tenant_wide_admin_consent_granted.yml +++ b/detections/cloud/azure_ad_tenant_wide_admin_consent_granted.yml @@ -1,6 +1,6 @@ name: Azure AD Tenant Wide Admin Consent Granted id: dc02c0ee-6ac0-4c7f-87ba-8ce43a4e4418 -version: 1 +version: 2 date: '2023-09-14' author: Mauricio Velazco, Splunk status: production @@ -10,14 +10,15 @@ description: The following analytic identifies instances where admin consent is search: > `azuread` operationName="Consent to application" | eval new_field=mvindex('properties.targetResources{}.modifiedProperties{}.newValue', 4) + | rename properties.* as * | rex field=new_field "ConsentType: (?[^\,]+)" - | stats max(_time) as _time by operationName, properties.initiatedBy.user.userPrincipalName, properties.targetResources{}.displayName, properties.targetResources{}.id, ConsentType + | stats count min(_time) as firstTime max(_time) as lastTime by operationName, user, targetResources{}.displayName, targetResources{}.id, ConsentType + | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `azure_ad_tenant_wide_admin_consent_granted_filter` 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. - Specifically, this analytic leverages the AuditLogs log category. + 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 Auditlogs log category. known_false_positives: Legitimate applications may be granted tenant wide consent, filter as needed. references: - https://attack.mitre.org/techniques/T1098/003/ @@ -27,18 +28,16 @@ references: - https://microsoft.github.io/Azure-Threat-Research-Matrix/Persistence/AZT501/AZT501-2/ tags: analytic_story: - - UPDATE_STORY_NAME + - Azure Active Directory Persistence asset_type: Azure AD - atomic_guid: - - UPDATE atomic_guid confidence: 50 impact: 90 - message: UPDATE message + message: Administrator $user$ consented an OAuth application for the tenant. mitre_attack_id: - T1098 - T1098.003 observable: - - name: properties.initiatedBy.user.userPrincipalName + - name: user type: User role: - Attacker @@ -50,8 +49,8 @@ tags: required_fields: - _time - operationName + - user - properties.targetResources{}.modifiedProperties{}.newValue - - properties.initiatedBy.user.userPrincipalName - properties.targetResources{}.displayName - properties.targetResources{}.id security_domain: identity @@ -59,5 +58,5 @@ tests: - name: True Positive Test attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.003/azure_ad_admin_consent/azure_ad_admin_consent.log - source: mscs:azure:eventhub - sourcetype: mscs:azure:eventhub \ No newline at end of file + source: Azure AD + sourcetype: azure:monitor:aad \ No newline at end of file From dcc70818871d298c1589cbbb1b740e2c8c33fb7a Mon Sep 17 00:00:00 2001 From: mvelazco Date: Thu, 26 Oct 2023 17:01:07 -0400 Subject: [PATCH 12/33] adding new detection --- ...k_user_consent_for_risky_apps_disabled.yml | 53 +++++++++++++++++++ ...ds_and_useragents_authentication_spike.yml | 2 +- 2 files changed, 54 insertions(+), 1 deletion(-) create mode 100644 detections/cloud/azure_ad_block_user_consent_for_risky_apps_disabled.yml 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 new file mode 100644 index 0000000000..471c5bdd0d --- /dev/null +++ b/detections/cloud/azure_ad_block_user_consent_for_risky_apps_disabled.yml @@ -0,0 +1,53 @@ +name: Azure AD Block User Consent For Risky Apps Disabled +id: 875de3d7-09bc-4916-8c0a-0929f4ced3d8 +version: 1 +date: '2023-10-26' +author: Mauricio Velazco, Splunk +status: production +type: TTP +data_source: [] +description: test +search: > + `azuread` operationName="Update authorization policy" + | rename properties.* as * + | eval index_number = if(mvfind('targetResources{}.modifiedProperties{}.displayName', "AllowUserConsentForRiskyApps") >= 0, mvfind('targetResources{}.modifiedProperties{}.displayName', "AllowUserConsentForRiskyApps"), -1) + | search index_number >= 0 + | eval AllowUserConsentForRiskyApps = mvindex('targetResources{}.modifiedProperties{}.newValue',index_number) + | search AllowUserConsentForRiskyApps = "[true]" + | stats count min(_time) as firstTime max(_time) as lastTime by user, src_ip, operationName, AllowUserConsentForRiskyApps + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `azure_ad_block_user_consent_for_risky_apps_disabled_filter` +how_to_implement: UPDATE_HOW_TO_IMPLEMENT +known_false_positives: UPDATE_KNOWN_FALSE_POSITIVES +references: +- https://attack.mitre.org/techniques/T1562/ +- https://goodworkaround.com/2020/10/19/a-look-behind-the-azure-ad-permission-classifications-preview/ +tags: + analytic_story: + - UPDATE_STORY_NAME + asset_type: UPDATE asset_type + confidence: 50 + impact: 60 + message: UPDATE message + mitre_attack_id: + - T1562 + observable: + - name: user + type: User + role: + - Attacker + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + risk_score: 30 + required_fields: + - _time + security_domain: identity +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1562/azuread_disable_blockconsent_for_riskapps/azuread_disable_blockconsent_for_riskapps.log + source: Azure Ad + sourcetype: azure:monitor:aad diff --git a/detections/cloud/azure_ad_multiple_appids_and_useragents_authentication_spike.yml b/detections/cloud/azure_ad_multiple_appids_and_useragents_authentication_spike.yml index 0c74387e40..d7e80b73db 100644 --- a/detections/cloud/azure_ad_multiple_appids_and_useragents_authentication_spike.yml +++ b/detections/cloud/azure_ad_multiple_appids_and_useragents_authentication_spike.yml @@ -6,7 +6,7 @@ author: Mauricio Velazco, Splunk status: production type: Anomaly data_source: [] -description: This analytic is crafted to identify unusual and potentially malicious authentication activity within an Azure AD environment. It triggers when a single user account is involved in more than 8 authentication attempts, using 3 or more unique application IDs and more than 5 unique user agents within a short timeframe. This pattern is atypical for regular user behavior and may indicate an adversary’s attempt to probe the environment, testing for multi-factor authentication requirements across different applications and platforms. The detection is based on analysis of Azure AD audit logs, specifically focusing on authentication events. It employs statistical thresholds to highlight instances where the volume of authentication attempts and the diversity of application IDs and user agents associated with a single user account exceed normal parameters. Identifying this behavior is crucial as it provides an early indication of potential account compromise. Adversaries, once in possession of user credentials, often conduct reconnaissance to understand the security controls in place, including multi-factor authentication configurations. Tools like Invoke-MFASweep are commonly used for this purpose, automating the process of testing different user agents and application IDs to bypass MFA. By detecting these initial probing attempts, security teams can swiftly respond, potentially stopping an attack in its early stages and preventing further unauthorized access. This proactive stance is vital for maintaining the integrity of the organization’s security posture. If validated as a true positive, this detection points to a compromised account, signaling that an attacker is actively attempting to navigate security controls to maintain access and potentially escalate privileges. This could lead to further exploitation, lateral movement within the network, and eventual data exfiltration. Recognizing and responding to this early stage of an attack is vital for preventing substantial harm and safeguarding sensitive organizational data and systems. +description: This analytic is crafted to identify unusual and potentially malicious authentication activity within an Azure AD environment. It triggers when a single user account is involved in more than 8 authentication attempts, using 3 or more unique application IDs and more than 5 unique user agents within a short timeframe. This pattern is atypical for regular user behavior and may indicate an adversary's attempt to probe the environment, testing for multi-factor authentication requirements across different applications and platforms. The detection is based on analysis of Azure AD audit logs, specifically focusing on authentication events. It employs statistical thresholds to highlight instances where the volume of authentication attempts and the diversity of application IDs and user agents associated with a single user account exceed normal parameters. Identifying this behavior is crucial as it provides an early indication of potential account compromise. Adversaries, once in possession of user credentials, often conduct reconnaissance to understand the security controls in place, including multi-factor authentication configurations. Tools like Invoke-MFASweep are commonly used for this purpose, automating the process of testing different user agents and application IDs to bypass MFA. By detecting these initial probing attempts, security teams can swiftly respond, potentially stopping an attack in its early stages and preventing further unauthorized access. This proactive stance is vital for maintaining the integrity of the organization's security posture. If validated as a true positive, this detection points to a compromised account, signaling that an attacker is actively attempting to navigate security controls to maintain access and potentially escalate privileges. This could lead to further exploitation, lateral movement within the network, and eventual data exfiltration. Recognizing and responding to this early stage of an attack is vital for preventing substantial harm and safeguarding sensitive organizational data and systems. search: ' `azuread` category=SignInLogs operationName="Sign-in activity" (properties.authenticationRequirement="multiFactorAuthentication" AND properties.status.additionalDetails="MFA required in Azure AD") OR (properties.authenticationRequirement=singleFactorAuthentication AND "properties.authenticationDetails{}.succeeded"=true) | bucket span=5m _time | rename properties.* as * From b5acee8b5ad36f4c617c773f53163f79dc6d035c Mon Sep 17 00:00:00 2001 From: mvelazco Date: Fri, 27 Oct 2023 13:53:20 -0400 Subject: [PATCH 13/33] adding detection --- ..._consent_blocked_for_risky_application.yml | 60 +++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 detections/cloud/azure_ad_user_consent_blocked_for_risky_application.yml 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 new file mode 100644 index 0000000000..43a49dcffe --- /dev/null +++ b/detections/cloud/azure_ad_user_consent_blocked_for_risky_application.yml @@ -0,0 +1,60 @@ +name: Azure AD User Consent Blocked for Risky Application +id: 06b8ec9a-d3b5-4882-8f16-04b4d10f5eab +version: 1 +date: '2023-10-27' +author: Mauricio Velazco, Splunk +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: > + `azuread` 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) + | eval permissions_index = if(mvfind('targetResources{}.modifiedProperties{}.displayName', "ConsentAction.Permissions") >= 0, mvfind('targetResources{}.modifiedProperties{}.displayName', "ConsentAction.Permissions"), -1) + | search reason_index >= 0 + | eval reason = mvindex('targetResources{}.modifiedProperties{}.newValue',reason_index) + | eval permissions = mvindex('targetResources{}.modifiedProperties{}.newValue',permissions_index) + | search reason = "\"Risky application detected\"" + | rex field=permissions "Scope: (?[^,]+)" + | stats count min(_time) as firstTime max(_time) as lastTime by operationName, user, reason, Scope + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `azure_ad_user_consent_blocked_for_risky_application_filter` +how_to_implement: UPDATE_HOW_TO_IMPLEMENT +known_false_positives: UPDATE_KNOWN_FALSE_POSITIVES +references: +- https://attack.mitre.org/techniques/T1528/ +- https://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-oauth-applications-used-to-compromise-email-servers-and-spread-spam/ +- https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/protect-against-consent-phishing +- https://learn.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth +- https://www.alteredsecurity.com/post/introduction-to-365-stealer +- https://github.com/AlteredSecurity/365-Stealer +tags: + analytic_story: + - Azure Active Directory Account Takeover + asset_type: Azure AD tenant + confidence: 100 + impact: 30 + message: Azure AD has blocked $user$ attempt to grant to consent to an application deemed risky. + mitre_attack_id: + - T1528 + observable: + - name: user + type: User + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + risk_score: 30 + required_fields: + - _time + security_domain: identity +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1528/azure_ad_user_consent_blocked/azure_ad_user_consent_blocked.log + source: Azure AD + sourcetype: azure:monitor:aad \ No newline at end of file From b4356daa642b5cf21c3b08aa573a6c05af9a7dfa Mon Sep 17 00:00:00 2001 From: mvelazco Date: Fri, 27 Oct 2023 16:25:55 -0400 Subject: [PATCH 14/33] updating macro. adding new detection. --- ...k_user_consent_for_risky_apps_disabled.yml | 2 +- ...ds_and_useragents_authentication_spike.yml | 2 +- ...th_application_consent_granted_by_user.yml | 53 +++++++++++++++++++ ...e_ad_tenant_wide_admin_consent_granted.yml | 2 +- ..._consent_blocked_for_risky_application.yml | 2 +- macros/azure_monitor_aad.yml | 4 ++ macros/azuread.yml | 2 +- 7 files changed, 62 insertions(+), 5 deletions(-) create mode 100644 detections/cloud/azure_ad_oauth_application_consent_granted_by_user.yml create mode 100644 macros/azure_monitor_aad.yml 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 471c5bdd0d..db686fabe6 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 @@ -8,7 +8,7 @@ type: TTP data_source: [] description: test search: > - `azuread` operationName="Update authorization policy" + `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) | search index_number >= 0 diff --git a/detections/cloud/azure_ad_multiple_appids_and_useragents_authentication_spike.yml b/detections/cloud/azure_ad_multiple_appids_and_useragents_authentication_spike.yml index d7e80b73db..a40bfe0408 100644 --- a/detections/cloud/azure_ad_multiple_appids_and_useragents_authentication_spike.yml +++ b/detections/cloud/azure_ad_multiple_appids_and_useragents_authentication_spike.yml @@ -7,7 +7,7 @@ status: production type: Anomaly data_source: [] description: This analytic is crafted to identify unusual and potentially malicious authentication activity within an Azure AD environment. It triggers when a single user account is involved in more than 8 authentication attempts, using 3 or more unique application IDs and more than 5 unique user agents within a short timeframe. This pattern is atypical for regular user behavior and may indicate an adversary's attempt to probe the environment, testing for multi-factor authentication requirements across different applications and platforms. The detection is based on analysis of Azure AD audit logs, specifically focusing on authentication events. It employs statistical thresholds to highlight instances where the volume of authentication attempts and the diversity of application IDs and user agents associated with a single user account exceed normal parameters. Identifying this behavior is crucial as it provides an early indication of potential account compromise. Adversaries, once in possession of user credentials, often conduct reconnaissance to understand the security controls in place, including multi-factor authentication configurations. Tools like Invoke-MFASweep are commonly used for this purpose, automating the process of testing different user agents and application IDs to bypass MFA. By detecting these initial probing attempts, security teams can swiftly respond, potentially stopping an attack in its early stages and preventing further unauthorized access. This proactive stance is vital for maintaining the integrity of the organization's security posture. If validated as a true positive, this detection points to a compromised account, signaling that an attacker is actively attempting to navigate security controls to maintain access and potentially escalate privileges. This could lead to further exploitation, lateral movement within the network, and eventual data exfiltration. Recognizing and responding to this early stage of an attack is vital for preventing substantial harm and safeguarding sensitive organizational data and systems. -search: ' `azuread` category=SignInLogs operationName="Sign-in activity" (properties.authenticationRequirement="multiFactorAuthentication" AND properties.status.additionalDetails="MFA required in Azure AD") OR (properties.authenticationRequirement=singleFactorAuthentication AND "properties.authenticationDetails{}.succeeded"=true) +search: ' `azure_monitor_aad` category=SignInLogs operationName="Sign-in activity" (properties.authenticationRequirement="multiFactorAuthentication" AND properties.status.additionalDetails="MFA required in Azure AD") OR (properties.authenticationRequirement=singleFactorAuthentication AND "properties.authenticationDetails{}.succeeded"=true) | bucket span=5m _time | rename properties.* as * | stats dc(_raw) as failed_attempts dc(appId) as unique_app_ids dc(userAgent) as unique_user_agents values(appDisplayName) values(deviceDetail.operatingSystem) by _time user src_ip 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 new file mode 100644 index 0000000000..303127e213 --- /dev/null +++ b/detections/cloud/azure_ad_oauth_application_consent_granted_by_user.yml @@ -0,0 +1,53 @@ +name: Azure AD OAuth Application Consent Granted By User +id: 10ec9031-015b-4617-b453-c0c1ab729007 +version: 1 +date: '2023-10-27' +author: Mauricio Velazco, Splunk +status: production +type: TTP +data_source: +- UPDATE_DATA_SOURCE +description: UPDATE_DESCRIPTION +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) + | eval permissions = mvindex('targetResources{}.modifiedProperties{}.newValue',permissions_index) + | rex field=permissions "Scope: (?[^,]+)" + | stats count min(_time) as firstTime max(_time) as lastTime by operationName, user, Scope + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `azure_ad_oauth_application_consent_granted_by_user_filter` +how_to_implement: UPDATE_HOW_TO_IMPLEMENT +known_false_positives: UPDATE_KNOWN_FALSE_POSITIVES +references: +- REFERENCE +tags: + analytic_story: + - UPDATE_STORY_NAME + asset_type: Azure AD + confidence: 60 + impact: 60 + message: UPDATE message + mitre_attack_id: + - T1003.002 + observable: + - name: user + type: User + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + risk_score: 36 + required_fields: + - UPDATE_required_fields + security_domain: identity +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1528/azure_ad_user_consent_granted/azure_ad_user_consent_granted.log + source: Azure AD + sourcetype: azure:monitor:aad + 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 674a6fea81..5d86bf4ab4 100644 --- a/detections/cloud/azure_ad_tenant_wide_admin_consent_granted.yml +++ b/detections/cloud/azure_ad_tenant_wide_admin_consent_granted.yml @@ -8,7 +8,7 @@ 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: > - `azuread` operationName="Consent to application" + `azure_monitor_aad` operationName="Consent to application" | eval new_field=mvindex('properties.targetResources{}.modifiedProperties{}.newValue', 4) | rename properties.* as * | rex field=new_field "ConsentType: (?[^\,]+)" 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 43a49dcffe..d6bb3933b0 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 @@ -8,7 +8,7 @@ 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: > - `azuread` operationName="Consent to application" properties.result=failure + `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) | eval permissions_index = if(mvfind('targetResources{}.modifiedProperties{}.displayName', "ConsentAction.Permissions") >= 0, mvfind('targetResources{}.modifiedProperties{}.displayName', "ConsentAction.Permissions"), -1) diff --git a/macros/azure_monitor_aad.yml b/macros/azure_monitor_aad.yml new file mode 100644 index 0000000000..034411f4c3 --- /dev/null +++ b/macros/azure_monitor_aad.yml @@ -0,0 +1,4 @@ +definition: sourcetype=azure:monitor:aad +description: customer specific splunk configurations(eg- index, source, sourcetype). + Replace the macro definition with configurations for your Splunk Environmnent. +name: azure_monitor_aad diff --git a/macros/azuread.yml b/macros/azuread.yml index 60a2ab78d3..bff933179e 100644 --- a/macros/azuread.yml +++ b/macros/azuread.yml @@ -1,4 +1,4 @@ -definition: sourcetype=mscs:azure:eventhub OR sourcetype=azure:monitor:aad +definition: sourcetype=mscs:azure:eventhub description: customer specific splunk configurations(eg- index, source, sourcetype). Replace the macro definition with configurations for your Splunk Environmnent. name: azuread From 15453d51aebf7b12104f257081aa4404262d9f99 Mon Sep 17 00:00:00 2001 From: mvelazco Date: Fri, 27 Oct 2023 16:56:14 -0400 Subject: [PATCH 15/33] update sourcetype --- detections/cloud/azure_ad_device_code_authentication.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/detections/cloud/azure_ad_device_code_authentication.yml b/detections/cloud/azure_ad_device_code_authentication.yml index 589b918f41..511d710f7e 100644 --- a/detections/cloud/azure_ad_device_code_authentication.yml +++ b/detections/cloud/azure_ad_device_code_authentication.yml @@ -15,7 +15,7 @@ description: The following analytic identifies the execution of the Azure Device in adversaries gaining unauthorized access to Azure AD, Exchange mailboxes, and the target's Outlook Web Application (OWA). This attack technique was detailed by security researchers including Bobby Cooke, Stephan Borosh, and others. It's crucial for organizations to be aware of this threat, as it can lead to unauthorized access and potential data breaches. -search: '`azuread` category=SignInLogs "properties.authenticationProtocol"=deviceCode +search: '`azure_monitor_aad` category=SignInLogs "properties.authenticationProtocol"=deviceCode | rename properties.* as * | stats count min(_time) as firstTime max(_time) as lastTime by user src_ip, appDisplayName, userAgent | `security_content_ctime(firstTime)` From cff416851a5f2192c73ae0a87d33d9ed479a2dd3 Mon Sep 17 00:00:00 2001 From: mvelazco Date: Mon, 30 Oct 2023 12:57:06 -0400 Subject: [PATCH 16/33] new detection --- ...th_application_consent_granted_by_user.yml | 4 +- ..._consent_blocked_for_risky_application.yml | 4 +- ...r_consent_denied_for_oauth_application.yml | 59 +++++++++++++++++++ 3 files changed, 65 insertions(+), 2 deletions(-) create mode 100644 detections/cloud/azure_ad_user_consent_denied_for_oauth_application.yml 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 303127e213..80c0dcacee 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 @@ -18,7 +18,9 @@ search: > | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `azure_ad_oauth_application_consent_granted_by_user_filter` -how_to_implement: UPDATE_HOW_TO_IMPLEMENT +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: UPDATE_KNOWN_FALSE_POSITIVES references: - REFERENCE 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 d6bb3933b0..0519033b8f 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 @@ -21,7 +21,9 @@ search: > | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `azure_ad_user_consent_blocked_for_risky_application_filter` -how_to_implement: UPDATE_HOW_TO_IMPLEMENT +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: UPDATE_KNOWN_FALSE_POSITIVES references: - https://attack.mitre.org/techniques/T1528/ diff --git a/detections/cloud/azure_ad_user_consent_denied_for_oauth_application.yml b/detections/cloud/azure_ad_user_consent_denied_for_oauth_application.yml new file mode 100644 index 0000000000..8c2c8266a6 --- /dev/null +++ b/detections/cloud/azure_ad_user_consent_denied_for_oauth_application.yml @@ -0,0 +1,59 @@ +name: Azure AD User Consent Denied for OAuth Application +id: bb093c30-d860-4858-a56e-cd0895d5b49c +version: 1 +date: '2023-10-27' +author: Mauricio Velazco, Splunk +status: production +type: TTP +data_source: [] +description: The following analytic identifies instances where a user has actively denied consent to an OAuth application seeking permissions within the Azure AD environment. This suggests that the user either recognized something suspicious about the application or chose not to grant it the requested permissions for other reasons. This detection leverages the Azure AD's audit logs, specifically focusing on events related to user consent actions. By filtering for denied consent actions associated with OAuth applications, the analytic captures instances where users have actively rejected permission requests. While user-denied consents can be routine, they can also be indicative of users spotting potentially suspicious or unfamiliar applications. By monitoring these denied consent attempts, security teams can gain insights into applications that might be perceived as risky or untrusted by users. It can also serve as a feedback loop for security awareness training, indicating that users are being cautious about granting permissions. If the detection is a true positive, it indicates that a user has actively prevented an OAuth application from gaining the permissions it requested. While this is a proactive security measure on the user's part, it's essential for security teams to review the context of the denial. Understanding why certain applications are being denied can help in refining application whitelisting policies and ensuring that no malicious applications are attempting to gain access. +search: ' `azure_monitor_aad` operationName="Sign-in activity" properties.status.errorCode=65004 + | rename properties.* as * + | stats count min(_time) as firstTime max(_time) as lastTime by operationName, user, appDisplayName, status.failureReason + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `azure_ad_user_consent_denied_for_oauth_application_filter`' +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 SignInLogs log category. +known_false_positives: UPDATE_KNOWN_FALSE_POSITIVES +references: +- https://attack.mitre.org/techniques/T1528/ +- https://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-oauth-applications-used-to-compromise-email-servers-and-spread-spam/ +- https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/protect-against-consent-phishing +- https://learn.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth +- https://www.alteredsecurity.com/post/introduction-to-365-stealer +- https://github.com/AlteredSecurity/365-Stealer +tags: + analytic_story: + - UPDATE_STORY_NAME + asset_type: UPDATE asset_type + confidence: 60 + impact: 60 + message: UPDATE message + mitre_attack_id: + - T1528 + observable: + - name: user + type: User + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + risk_score: 36 + required_fields: + - _time + - operationName + - properties.status.errorCode + - user + - properties.appDisplayName + - status.failureReason + security_domain: identity +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1528/azure_ad_user_consent_declined/azure_ad_user_consent_declined.log + source: Azure AD + sourcetype: azure:monitor:aad From a62bde4f8f6b762459d8a17a8274cb41bdc056a4 Mon Sep 17 00:00:00 2001 From: mvelazco Date: Mon, 30 Oct 2023 15:35:50 -0400 Subject: [PATCH 17/33] updates --- ...k_user_consent_for_risky_apps_disabled.yml | 21 ++++++++++----- ...th_application_consent_granted_by_user.yml | 26 ++++++++++++------- ..._consent_blocked_for_risky_application.yml | 4 +++ ...r_consent_denied_for_oauth_application.yml | 8 +++--- 4 files changed, 40 insertions(+), 19 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 db686fabe6..51dd588b31 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 @@ -6,7 +6,7 @@ author: Mauricio Velazco, Splunk status: production type: TTP data_source: [] -description: test +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: > `azure_monitor_aad` operationName="Update authorization policy" | rename properties.* as * @@ -18,18 +18,22 @@ search: > | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `azure_ad_block_user_consent_for_risky_apps_disabled_filter` -how_to_implement: UPDATE_HOW_TO_IMPLEMENT -known_false_positives: UPDATE_KNOWN_FALSE_POSITIVES +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 references: - https://attack.mitre.org/techniques/T1562/ - https://goodworkaround.com/2020/10/19/a-look-behind-the-azure-ad-permission-classifications-preview/ +- https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-risk-based-step-up-consent +- https://learn.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth tags: analytic_story: - - UPDATE_STORY_NAME - asset_type: UPDATE asset_type + - Azure Active Directory Account Takeover + asset_type: Azure AD confidence: 50 impact: 60 - message: UPDATE message + message: User $user$ disabled the BlockUserConsentForRiskyApps Azure AD setting. mitre_attack_id: - T1562 observable: @@ -44,6 +48,11 @@ tags: risk_score: 30 required_fields: - _time + - operationName + - properties.targetResources{}.modifiedProperties{}.displayName + - properties.targetResources{}.modifiedProperties{}.newValue + - user + - src_ip security_domain: identity tests: - name: True Positive Test 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 80c0dcacee..7ec45152b2 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 @@ -5,9 +5,8 @@ date: '2023-10-27' author: Mauricio Velazco, Splunk status: production type: TTP -data_source: -- UPDATE_DATA_SOURCE -description: UPDATE_DESCRIPTION +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: > `azure_monitor_aad` operationName="Consent to application" properties.result=success | rename properties.* as * @@ -21,18 +20,23 @@ 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: UPDATE_KNOWN_FALSE_POSITIVES +known_false_positives: False positives may occur if users are granting consents as part of legitimate application integrations or setups. It is crucial to review the application and the permissions it requests to ensure they align with organizational policies and security best practices. references: -- REFERENCE +- https://attack.mitre.org/techniques/T1528/ +- https://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-oauth-applications-used-to-compromise-email-servers-and-spread-spam/ +- https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/protect-against-consent-phishing +- https://learn.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth +- https://www.alteredsecurity.com/post/introduction-to-365-stealer +- https://github.com/AlteredSecurity/365-Stealer tags: analytic_story: - - UPDATE_STORY_NAME + - Azure Active Directory Account Takeover asset_type: Azure AD confidence: 60 impact: 60 - message: UPDATE message + message: User $user$ consented an OAuth application. mitre_attack_id: - - T1003.002 + - T1528 observable: - name: user type: User @@ -44,7 +48,11 @@ tags: - Splunk Cloud risk_score: 36 required_fields: - - UPDATE_required_fields + - _time + - operationName + - properties.targetResources{}.modifiedProperties{}.displayName + - properties.targetResources{}.modifiedProperties{}.newValue + - user security_domain: identity tests: - name: True Positive Test 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 0519033b8f..5673b5333b 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 @@ -53,6 +53,10 @@ tags: risk_score: 30 required_fields: - _time + - operationName + - properties.result + - properties.targetResources{}.modifiedProperties{}.displayName + - properties.targetResources{}.modifiedProperties{}.newValue security_domain: identity tests: - name: True Positive Test diff --git a/detections/cloud/azure_ad_user_consent_denied_for_oauth_application.yml b/detections/cloud/azure_ad_user_consent_denied_for_oauth_application.yml index 8c2c8266a6..039f7e5d33 100644 --- a/detections/cloud/azure_ad_user_consent_denied_for_oauth_application.yml +++ b/detections/cloud/azure_ad_user_consent_denied_for_oauth_application.yml @@ -16,7 +16,7 @@ search: ' `azure_monitor_aad` operationName="Sign-in activity" properties.status 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 SignInLogs log category. -known_false_positives: UPDATE_KNOWN_FALSE_POSITIVES +known_false_positives: Users may deny consent for legitimate applications by mistake, filter as needed. references: - https://attack.mitre.org/techniques/T1528/ - https://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-oauth-applications-used-to-compromise-email-servers-and-spread-spam/ @@ -26,11 +26,11 @@ references: - https://github.com/AlteredSecurity/365-Stealer tags: analytic_story: - - UPDATE_STORY_NAME - asset_type: UPDATE asset_type + - Azure Active Directory Account Takeover + asset_type: Azure AD confidence: 60 impact: 60 - message: UPDATE message + message: User $user$ denied consent for an OAuth application. mitre_attack_id: - T1528 observable: From d2e1de3b670214085f9fab4ce33ebe6cd4d8648b Mon Sep 17 00:00:00 2001 From: mvelazco Date: Tue, 31 Oct 2023 15:02:55 -0400 Subject: [PATCH 18/33] adding detection --- .../azure_ad_new_mfa_method_registered.yml | 67 +++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 detections/cloud/azure_ad_new_mfa_method_registered.yml diff --git a/detections/cloud/azure_ad_new_mfa_method_registered.yml b/detections/cloud/azure_ad_new_mfa_method_registered.yml new file mode 100644 index 0000000000..2aaa87fb98 --- /dev/null +++ b/detections/cloud/azure_ad_new_mfa_method_registered.yml @@ -0,0 +1,67 @@ +name: Azure AD New MFA Method Registered +id: 0488e814-eb81-42c3-9f1f-b2244973e3a3 +version: 1 +date: '2023-10-31' +author: Mauricio Velazco, Splunk +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: > + `azure_monitor_aad` operationName="Update user" + | rename properties.* as * + | eval propertyName = mvindex('targetResources{}.modifiedProperties{}.displayName', 0) + | search propertyName = StrongAuthenticationMethod + | eval oldvalue = mvindex('targetResources{}.modifiedProperties{}.oldValue',0) + | eval newvalue = mvindex('targetResources{}.modifiedProperties{}.newValue',0) + | rex field=newvalue max_match=0 "(?i)(?\"MethodType\")" + | rex field=oldvalue max_match=0 "(?i)(?\"MethodType\")" + | eval count_new_method_type = coalesce(mvcount(new_method_type), 0) + | eval count_old_method_type = coalesce(mvcount(old_method_type), 0) + | stats earliest(_time) as firstTime latest(_time) as lastTime values(propertyName) by user newvalue oldvalue + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `azure_ad_new_mfa_method_registered_filter` +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: Users may register MFA methods legitimally, investigate and filter as needed. +references: +- https://attack.mitre.org/techniques/T1098/005/ +- https://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/ +- https://www.csoonline.com/article/573451/sophisticated-bec-scammers-bypass-microsoft-365-multi-factor-authentication.html +tags: + analytic_story: + - Azure Active Directory Persistence + asset_type: Azure AD + confidence: 50 + impact: 60 + message: A new MFA method was registered for user $user$ + mitre_attack_id: + - T1098 + - T1098.005 + observable: + - name: user + type: User + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + risk_score: 30 + required_fields: + - _time + - operationName + - properties.targetResources{}.modifiedProperties{}.displayName + - properties.targetResources{}.modifiedProperties{}.oldValue + - properties.targetResources{}.modifiedProperties{}.newValue + - user + security_domain: identity +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1098.005/azure_ad_register_new_mfa_method/azure_ad_register_new_mfa_method.log + source: Azure AD + sourcetype: azure:monitor:aad + From 31d2d20ca2da4dff2e0c1657797f4042ac9eadc4 Mon Sep 17 00:00:00 2001 From: mvelazco Date: Tue, 31 Oct 2023 16:17:11 -0400 Subject: [PATCH 19/33] adding detection --- ..._multiple_denied_mfa_requests_for_user.yml | 64 +++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 detections/cloud/azure_ad_multiple_denied_mfa_requests_for_user.yml diff --git a/detections/cloud/azure_ad_multiple_denied_mfa_requests_for_user.yml b/detections/cloud/azure_ad_multiple_denied_mfa_requests_for_user.yml new file mode 100644 index 0000000000..4f675e3670 --- /dev/null +++ b/detections/cloud/azure_ad_multiple_denied_mfa_requests_for_user.yml @@ -0,0 +1,64 @@ +name: Azure AD Multiple Denied MFA Requests For User +id: d0895c20-de71-4fd2-b56c-3fcdb888eba1 +version: 1 +date: '2023-10-31' +author: Mauricio Velazco, Splunk +status: production +type: TTP +data_source: [] +description: This analytic targets the detection of an unusually high number of denied Multi-Factor Authentication (MFA) requests for a single user within a 10-minute window, specifically identifying instances where more than nine MFA prompts were declined by the user. Utilizing Azure Active Directory (Azure AD) sign-in logs, particularly focusing on "Sign-in activity" events, it filters for scenarios where the MFA request was denied due to the user declining the authentication, as indicated by error code 500121 and additional details stating "MFA denied; user declined the authentication." The data is then aggregated into 10-minute intervals, counting distinct raw events and capturing the earliest and latest times of occurrence for each user. This behavior is significant for a Security Operations Center (SOC) as it could be an early indicator of a targeted attack or an account compromise attempt, with an attacker having obtained the user's credentials and the user actively declining the MFA prompts, preventing unauthorized access. A true positive detection would imply that an attacker is on the verge of gaining full access to the user's account, posing a threat that could lead to data exfiltration, lateral movement, or further malicious activities within the organization, necessitating immediate investigation and response to safeguard the organization's assets. +search: '`azure_monitor_aad` category=SignInLogs category="Sign-in activity" + | rename properties.* as * + | search status.errorCode=500121 status.additionalDetails="MFA denied; user declined the authentication" + | bucket span=10m _time + | stats dc(_raw) AS mfa_prompts earliest(_time) as firstTime latest(_time) as lastTime by user, status.additionalDetails, appDisplayName, userAgent, _time + | where mfa_prompts > 9 + | `security_content_ctime(firstTime)` + | `security_content_ctime(lastTime)` + | `azure_ad_multiple_denied_mfa_requests_for_user_filter`' +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 Signin log category. +known_false_positives: UPDATE_KNOWN_FALSE_POSITIVES +references: +- https://www.mandiant.com/resources/blog/russian-targeting-gov-business +- https://arstechnica.com/information-technology/2022/03/lapsus-and-solar-winds-hackers-both-use-the-same-old-trick-to-bypass-mfa/ +- https://therecord.media/russian-hackers-bypass-2fa-by-annoying-victims-with-repeated-push-notifications/ +- https://attack.mitre.org/techniques/T1621/ +- https://attack.mitre.org/techniques/T1078/004/ +tags: + analytic_story: + - Azure Active Directory Account Takeover + asset_type: Azure Active Directory + confidence: 90 + impact: 60 + atomic_guid: [] + message: User $user$ denied more than 9 MFA requests in a timespan of 10 minutes. + mitre_attack_id: + - T1621 + observable: + - name: user + type: User + role: + - Victim + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + risk_score: 54 + required_fields: + - _time + - category + - category + - properties.status.errorCode + - properties.status.additionalDetails + - user + - properties.appDisplayName + - properties.userAgent + security_domain: identity +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/azure_ad_multiple_denied_mfa_requests/azure_ad_multiple_denied_mfa_requests.log + source: Azure AD + sourcetype: azure:monitor:aad From 77b591f42424726e979e52d5482d5ea1aa910225 Mon Sep 17 00:00:00 2001 From: mvelazco Date: Tue, 31 Oct 2023 16:43:27 -0400 Subject: [PATCH 20/33] update detection --- .../cloud/azure_ad_multiple_denied_mfa_requests_for_user.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/detections/cloud/azure_ad_multiple_denied_mfa_requests_for_user.yml b/detections/cloud/azure_ad_multiple_denied_mfa_requests_for_user.yml index 4f675e3670..01a365c2a8 100644 --- a/detections/cloud/azure_ad_multiple_denied_mfa_requests_for_user.yml +++ b/detections/cloud/azure_ad_multiple_denied_mfa_requests_for_user.yml @@ -7,7 +7,7 @@ status: production type: TTP data_source: [] description: This analytic targets the detection of an unusually high number of denied Multi-Factor Authentication (MFA) requests for a single user within a 10-minute window, specifically identifying instances where more than nine MFA prompts were declined by the user. Utilizing Azure Active Directory (Azure AD) sign-in logs, particularly focusing on "Sign-in activity" events, it filters for scenarios where the MFA request was denied due to the user declining the authentication, as indicated by error code 500121 and additional details stating "MFA denied; user declined the authentication." The data is then aggregated into 10-minute intervals, counting distinct raw events and capturing the earliest and latest times of occurrence for each user. This behavior is significant for a Security Operations Center (SOC) as it could be an early indicator of a targeted attack or an account compromise attempt, with an attacker having obtained the user's credentials and the user actively declining the MFA prompts, preventing unauthorized access. A true positive detection would imply that an attacker is on the verge of gaining full access to the user's account, posing a threat that could lead to data exfiltration, lateral movement, or further malicious activities within the organization, necessitating immediate investigation and response to safeguard the organization's assets. -search: '`azure_monitor_aad` category=SignInLogs category="Sign-in activity" +search: '`azure_monitor_aad` category=SignInLogs operationName="Sign-in activity" | rename properties.* as * | search status.errorCode=500121 status.additionalDetails="MFA denied; user declined the authentication" | bucket span=10m _time From 1ff4ed036bb470e8feb5ddafd9cd3a39ed85a297 Mon Sep 17 00:00:00 2001 From: mvelazco Date: Tue, 31 Oct 2023 18:01:06 -0400 Subject: [PATCH 21/33] Update azure_ad_multiple_denied_mfa_requests_for_user.yml --- .../cloud/azure_ad_multiple_denied_mfa_requests_for_user.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/detections/cloud/azure_ad_multiple_denied_mfa_requests_for_user.yml b/detections/cloud/azure_ad_multiple_denied_mfa_requests_for_user.yml index 01a365c2a8..ba36801171 100644 --- a/detections/cloud/azure_ad_multiple_denied_mfa_requests_for_user.yml +++ b/detections/cloud/azure_ad_multiple_denied_mfa_requests_for_user.yml @@ -19,7 +19,7 @@ search: '`azure_monitor_aad` category=SignInLogs operationName="Sign-in activity 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 Signin log category. -known_false_positives: UPDATE_KNOWN_FALSE_POSITIVES +known_false_positives: Multiple denifed MFA requests in a short period of span may also be a sign of authentication errors. Investigate and filter as needed. references: - https://www.mandiant.com/resources/blog/russian-targeting-gov-business - https://arstechnica.com/information-technology/2022/03/lapsus-and-solar-winds-hackers-both-use-the-same-old-trick-to-bypass-mfa/ From 1741f91633580ac4989f191fad617a142822cc8a Mon Sep 17 00:00:00 2001 From: mvelazco Date: Wed, 1 Nov 2023 12:47:12 -0400 Subject: [PATCH 22/33] updating detections --- ..._multiple_denied_mfa_requests_for_user.yml | 1 + ..._multiple_failed_mfa_requests_for_user.yml | 33 ++++++++++--------- 2 files changed, 19 insertions(+), 15 deletions(-) diff --git a/detections/cloud/azure_ad_multiple_denied_mfa_requests_for_user.yml b/detections/cloud/azure_ad_multiple_denied_mfa_requests_for_user.yml index ba36801171..5900e68ae6 100644 --- a/detections/cloud/azure_ad_multiple_denied_mfa_requests_for_user.yml +++ b/detections/cloud/azure_ad_multiple_denied_mfa_requests_for_user.yml @@ -26,6 +26,7 @@ references: - https://therecord.media/russian-hackers-bypass-2fa-by-annoying-victims-with-repeated-push-notifications/ - https://attack.mitre.org/techniques/T1621/ - https://attack.mitre.org/techniques/T1078/004/ +- https://www.cisa.gov/sites/default/files/publications/fact-sheet-implement-number-matching-in-mfa-applications-508c.pdf tags: analytic_story: - Azure Active Directory Account Takeover diff --git a/detections/cloud/azure_ad_multiple_failed_mfa_requests_for_user.yml b/detections/cloud/azure_ad_multiple_failed_mfa_requests_for_user.yml index f88d9fdddf..1558973630 100644 --- a/detections/cloud/azure_ad_multiple_failed_mfa_requests_for_user.yml +++ b/detections/cloud/azure_ad_multiple_failed_mfa_requests_for_user.yml @@ -1,6 +1,6 @@ name: Azure AD Multiple Failed MFA Requests For User id: 264ea131-ab1f-41b8-90e0-33ad1a1888ea -version: 1 +version: 2 date: '2022-08-25' author: Mauricio Velazco, Gowthamaraj Rajendran, Splunk status: production @@ -8,8 +8,9 @@ type: TTP description: The following analytic identifies multiple failed multi-factor authentication requests for a single user within an Azure AD tenant. Error Code 500121 represents a failed attempt to authenticate using a second factor. Specifically, the analytic - triggers when more than 10 MFA user prompts fail within 10 minutes. Azure AD tenants - can be very different depending on the organization, Security teams should test + triggers when more than 10 MFA user prompts fail within 10 minutes. The reasons for these failure could be several, + like the user not responding in time or receiving multiple duplicate MFA requests. + Azure AD tenants can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS @@ -18,14 +19,15 @@ description: The following analytic identifies multiple failed multi-factor auth this technique to bypass multi-factor authentication controls as reported by Mandiant and others. data_source: [] -search: ' `azuread` category=SignInLogs properties.status.errorCode=500121 - | rename properties.* as * | bucket span=10m _time | stats dc(_raw) AS mfa_prompts - values(ipAddress) as ipAddress by userPrincipalName, status.additionalDetails, appDisplayName, - userAgent, _time | where mfa_prompts > 10 | `azure_ad_multiple_failed_mfa_requests_for_user_filter`' +search: ' `azure_monitor_aad` category=SignInLogs operationName="Sign-in activity" properties.status.errorCode=500121 properties.status.additionalDetails!="MFA denied; user declined the authentication" + | rename properties.* as * + | bucket span=10m _time + | stats dc(_raw) AS mfa_prompts earliest(_time) as firstTime latest(_time) as lastTime by user, status.additionalDetails, appDisplayName, userAgent, _time + | where mfa_prompts > 9 + | `azure_ad_multiple_failed_mfa_requests_for_user_filter`' 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. - Specifically, this analytic leverages the SignInLogs log category. + 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 Signin log category. known_false_positives: Multiple Failed MFA requests may also be a sign of authentication or application issues. Filter as needed. references: @@ -34,13 +36,14 @@ references: - https://therecord.media/russian-hackers-bypass-2fa-by-annoying-victims-with-repeated-push-notifications/ - https://attack.mitre.org/techniques/T1621/ - https://attack.mitre.org/techniques/T1078/004/ +- https://www.cisa.gov/sites/default/files/publications/fact-sheet-implement-number-matching-in-mfa-applications-508c.pdf tags: analytic_story: - Azure Active Directory Account Takeover asset_type: Azure Active Directory confidence: 90 impact: 60 - message: Multiple Failed MFA requests for user $userPrincipalName$ + message: User $user$ failed to complete MFA authentication more than 9 times in a timespan of 10 minutes. mitre_attack_id: - T1586 - T1586.003 @@ -48,7 +51,7 @@ tags: - T1078 - T1078.004 observable: - - name: userPrincipalName + - name: user type: User role: - Victim @@ -61,14 +64,14 @@ tags: - properties.status.errorCode - category - properties.authenticationDetails - - properties.userPrincipalName - properties.ipAddress + - user risk_score: 54 security_domain: identity tests: - name: True Positive Test attack_data: - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1621/multiple_failed_mfa_requests/azure-audit.log - source: mscs:azure:eventhub - sourcetype: mscs:azure:eventhub + source: Azure AD + sourcetype: azure:monitor:aad update_timestamp: true From 7b501ac590cd7137b56e3e3278be40fd091b73d9 Mon Sep 17 00:00:00 2001 From: mvelazco Date: Wed, 1 Nov 2023 17:37:56 -0400 Subject: [PATCH 23/33] Update azure_ad_multiple_failed_mfa_requests_for_user.yml --- .../cloud/azure_ad_multiple_failed_mfa_requests_for_user.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/detections/cloud/azure_ad_multiple_failed_mfa_requests_for_user.yml b/detections/cloud/azure_ad_multiple_failed_mfa_requests_for_user.yml index 1558973630..cabe8fbb50 100644 --- a/detections/cloud/azure_ad_multiple_failed_mfa_requests_for_user.yml +++ b/detections/cloud/azure_ad_multiple_failed_mfa_requests_for_user.yml @@ -17,7 +17,7 @@ description: The following analytic identifies multiple failed multi-factor auth messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant - and others. + and others. data_source: [] search: ' `azure_monitor_aad` category=SignInLogs operationName="Sign-in activity" properties.status.errorCode=500121 properties.status.additionalDetails!="MFA denied; user declined the authentication" | rename properties.* as * From a08846ec4719db23ca7ae988aa99e1116c6d15c8 Mon Sep 17 00:00:00 2001 From: pyth0n1c Date: Wed, 8 Nov 2023 13:36:34 -0800 Subject: [PATCH 24/33] add some testing --- .github/workflows/contentctl_test.yml | 29 +++++++++++++++++++++++++++ contentctl_test.yml | 20 ++++++++++++++++++ 2 files changed, 49 insertions(+) create mode 100644 .github/workflows/contentctl_test.yml diff --git a/.github/workflows/contentctl_test.yml b/.github/workflows/contentctl_test.yml new file mode 100644 index 0000000000..7c8fb8c2d0 --- /dev/null +++ b/.github/workflows/contentctl_test.yml @@ -0,0 +1,29 @@ +name: Initial contentctl test workflow + +# Trigger the workflow on pull request +on: + push: + pull_request: + types: [opened, reopened] + +jobs: + contentctl_test: + name: run contentctl test + runs-on: ubuntu-latest + steps: + - uses: actions/setup-python@v4 + with: + python-version: '3.9' #Available versions here - https://github.com/actions/python-versions/releases easy to change/make a matrix/use pypy + architecture: 'x64' # optional x64 or x86. Defaults to x64 if not specified + + - name: Everything + run: | + git clone https://github.com/splunk/contentctl + cd contentctl + git checkout diff_test_cli_support + git pull + python -m pip install poetry + poetry install + poetry shell + cd .. + contentctl test --mode changes --target_branch develop --test_branch TR_3232_azure_ad diff --git a/contentctl_test.yml b/contentctl_test.yml index 46b843fadc..47dab0f7ad 100644 --- a/contentctl_test.yml +++ b/contentctl_test.yml @@ -18,6 +18,26 @@ apps: splunkbase_path: null environment_path: ENVIRONMENT_PATH_NOT_SET force_local: false +- uid: 3110 + appid: Splunk_TA_linux_sysmon + title: Add-on for Linux Sysmon + description: null + release: 1.0.4 + local_path: null + http_path: https://attack-range-appbinaries.s3.us-west-2.amazonaws.com/Latest/splunk-add-on-for-microsoft-cloud-services_510.tgz + splunkbase_path: null + environment_path: ENVIRONMENT_PATH_NOT_SET + force_local: false +- uid: 4055 + appid: Splunk_TA_linux_sysmon + title: Add-on for Linux Sysmon + description: null + release: 1.0.4 + local_path: null + http_path: https://attack-range-appbinaries.s3.us-west-2.amazonaws.com/Latest/splunk-add-on-for-microsoft-office-365_430.tgz + splunkbase_path: null + environment_path: ENVIRONMENT_PATH_NOT_SET + force_local: false - uid: 742 appid: Splunk_TA_windows title: Splunk Add-on for Microsoft Windows From 304ae9aba4b0ca45d2626a1d5a5f2eac98dbaa3b Mon Sep 17 00:00:00 2001 From: pyth0n1c Date: Wed, 8 Nov 2023 13:40:14 -0800 Subject: [PATCH 25/33] can't run poetry shell in github --- .github/workflows/contentctl_test.yml | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/.github/workflows/contentctl_test.yml b/.github/workflows/contentctl_test.yml index 7c8fb8c2d0..c536c02fe2 100644 --- a/.github/workflows/contentctl_test.yml +++ b/.github/workflows/contentctl_test.yml @@ -24,6 +24,5 @@ jobs: git pull python -m pip install poetry poetry install - poetry shell - cd .. - contentctl test --mode changes --target_branch develop --test_branch TR_3232_azure_ad + poetry run contentctl -p ../ validate + poetry run contentctl -p ../ test --mode changes --target_branch develop --test_branch TR_3232_azure_ad From 7c76a975fb64ce75c45ec21d5c29fad37580e71d Mon Sep 17 00:00:00 2001 From: pyth0n1c Date: Wed, 8 Nov 2023 13:42:47 -0800 Subject: [PATCH 26/33] forgot to add checkout --- .github/workflows/contentctl_test.yml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.github/workflows/contentctl_test.yml b/.github/workflows/contentctl_test.yml index c536c02fe2..cf187e598b 100644 --- a/.github/workflows/contentctl_test.yml +++ b/.github/workflows/contentctl_test.yml @@ -16,6 +16,9 @@ jobs: python-version: '3.9' #Available versions here - https://github.com/actions/python-versions/releases easy to change/make a matrix/use pypy architecture: 'x64' # optional x64 or x86. Defaults to x64 if not specified + - name: Check out the repository code + uses: actions/checkout@v3 + - name: Everything run: | git clone https://github.com/splunk/contentctl From 96d7006e780ffd69c6be015c49239d6da351dc37 Mon Sep 17 00:00:00 2001 From: pyth0n1c Date: Wed, 8 Nov 2023 13:43:24 -0800 Subject: [PATCH 27/33] fix spacing --- .github/workflows/contentctl_test.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/contentctl_test.yml b/.github/workflows/contentctl_test.yml index cf187e598b..7e01bb6c9a 100644 --- a/.github/workflows/contentctl_test.yml +++ b/.github/workflows/contentctl_test.yml @@ -16,7 +16,7 @@ jobs: python-version: '3.9' #Available versions here - https://github.com/actions/python-versions/releases easy to change/make a matrix/use pypy architecture: 'x64' # optional x64 or x86. Defaults to x64 if not specified - - name: Check out the repository code + - name: Check out the repository code uses: actions/checkout@v3 - name: Everything From 51a3b86c99aa8348527b3461a1a98956a05f7fbd Mon Sep 17 00:00:00 2001 From: pyth0n1c Date: Wed, 8 Nov 2023 14:29:05 -0800 Subject: [PATCH 28/33] 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) From 6d6a603e1532b8dfbacfb380fd5486cd782ef1d0 Mon Sep 17 00:00:00 2001 From: pyth0n1c Date: Wed, 8 Nov 2023 14:39:37 -0800 Subject: [PATCH 29/33] More minor testing fixes --- contentctl.yml | 6 +++--- contentctl_test.yml | 4 +++- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/contentctl.yml b/contentctl.yml index abcf6ae395..e401807896 100644 --- a/contentctl.yml +++ b/contentctl.yml @@ -20,6 +20,6 @@ build_ssa: build_api: path_root: 'dist/api' enrichments: - attack_enrichment: true - cve_enrichment: true - splunk_app_enrichment: false \ No newline at end of file + attack_enrichment: false + cve_enrichment: false + splunk_app_enrichment: false diff --git a/contentctl_test.yml b/contentctl_test.yml index 47dab0f7ad..b471a3a525 100644 --- a/contentctl_test.yml +++ b/contentctl_test.yml @@ -1,4 +1,6 @@ -version_control_config: {} +version_control_config: + repo_path: . + repo_url: https://github.com/splunk/security_content infrastructure_config: infrastructure_type: container full_image_path: registry.hub.docker.com/splunk/splunk:latest From f77422a4d1ab8d64857beb45f7da6fa9c60e7aee Mon Sep 17 00:00:00 2001 From: pyth0n1c Date: Wed, 8 Nov 2023 14:43:57 -0800 Subject: [PATCH 30/33] fix pathing --- contentctl_test.yml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/contentctl_test.yml b/contentctl_test.yml index b471a3a525..c392607b7b 100644 --- a/contentctl_test.yml +++ b/contentctl_test.yml @@ -1,6 +1,7 @@ version_control_config: - repo_path: . + repo_path: ../ repo_url: https://github.com/splunk/security_content + infrastructure_config: infrastructure_type: container full_image_path: registry.hub.docker.com/splunk/splunk:latest From 7776ce872468af02a5d291455f0133603de0ee51 Mon Sep 17 00:00:00 2001 From: mvelazco Date: Wed, 8 Nov 2023 20:22:18 -0500 Subject: [PATCH 31/33] adding new detection --- ...ti_source_failed_authentications_spike.yml | 64 +++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 detections/cloud/azure_ad_multi_source_failed_authentications_spike.yml diff --git a/detections/cloud/azure_ad_multi_source_failed_authentications_spike.yml b/detections/cloud/azure_ad_multi_source_failed_authentications_spike.yml new file mode 100644 index 0000000000..bbfd112621 --- /dev/null +++ b/detections/cloud/azure_ad_multi_source_failed_authentications_spike.yml @@ -0,0 +1,64 @@ +name: Azure AD Multi-Source Failed Authentications Spike +id: 116e11a9-63ea-41eb-a66a-6a13bdc7d2c7 +version: 1 +date: '2023-11-08' +author: Mauricio Velazco, Splunk +status: production +type: Hunting +data_source: [] +description: UPDATE_DESCRIPTION +search: ' `azure_monitor_aad` category=SignInLogs properties.status.errorCode=50126 properties.authenticationDetails{}.succeeded=false + | rename properties.* as * + | bucket span=5m _time + | eval uniqueIPUserCombo = src_ip . "-" . user + | stats dc(uniqueIPUserCombo) as uniqueIpUserCombinations, dc(user) as uniqueUsers, dc(src_ip) as uniqueIPs, dc(location.countryOrRegion) as uniqueCountries values(user) as users, values(src_ip) as ips, values(user_agent) as user_agents, values(location.countryOrRegion) as countries by _time + | where uniqueIpUserCombinations > 10 AND uniqueUsers > 10 AND uniqueIPs > 10 + | `azure_ad_multi_source_failed_authentications_spike_filter`' +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 SignInLogs log category. +known_false_positives: UPDATE_KNOWN_FALSE_POSITIVES +references: +- https://attack.mitre.org/techniques/T1110/003/ +- https://docs.microsoft.com/en-us/security/compass/incident-response-playbook-password-spray +- https://www.cisa.gov/uscert/ncas/alerts/aa21-008a +- https://docs.microsoft.com/azure/active-directory/reports-monitoring/reference-sign-ins-error-codes +tags: + analytic_story: + - Azure Active Directory Account Takeover + asset_type: Azure AD + atomic_guid: [] + confidence: 60 + impact: 70 + message: UPDATE message + mitre_attack_id: + - T1586 + - T1586.003 + - T1110 + - T1110.003 + - T1110.004 + observable: + - name: src_ip + type: IP Address + role: + - Attacker + product: + - Splunk Enterprise + - Splunk Enterprise Security + - Splunk Cloud + risk_score: 42 + required_fields: + - _time + - category + - properties.authenticationDetails{}.succeeded + - properties.location.countryOrRegion + - user_agent + - src_ip + - user + security_domain: identity +tests: +- name: True Positive Test + attack_data: + - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/azure_ad_distributed_spray/azure_ad_distributed_spray.log + source: Azure AD + sourcetype: azure:monitor:aad From 5070105e8675b90fb69e9849a84dd3b79750fcfb Mon Sep 17 00:00:00 2001 From: mvelazco Date: Thu, 9 Nov 2023 10:18:19 -0500 Subject: [PATCH 32/33] update detection --- ...zure_ad_multi_source_failed_authentications_spike.yml | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/detections/cloud/azure_ad_multi_source_failed_authentications_spike.yml b/detections/cloud/azure_ad_multi_source_failed_authentications_spike.yml index bbfd112621..fdd93d2ad1 100644 --- a/detections/cloud/azure_ad_multi_source_failed_authentications_spike.yml +++ b/detections/cloud/azure_ad_multi_source_failed_authentications_spike.yml @@ -6,18 +6,19 @@ author: Mauricio Velazco, Splunk status: production type: Hunting data_source: [] -description: UPDATE_DESCRIPTION +description: This analytic detects potential distributed password spraying attacks within an Azure AD environment. It identifies a notable increase in failed authentication attempts across a variety of unique user-and-IP address combinations, originating from multiple source IP addresses and countries, and employing different user agents. Such patterns suggest an adversary's attempt to bypass security controls by using a range of IP addresses to test commonly used passwords against numerous user accounts. The detection scrutinizes SignInLogs from Azure AD logs, particularly focusing on events with error code 50126, which signals a failed authentication due to incorrect credentials. By collating data over a five-minute interval, the analytic computes the distinct counts of user-and-IP combinations, unique users, source IPs, and countries. It then applies a set of thresholds to these metrics to pinpoint unusual activities that could indicate a coordinated attack effort. The thresholds set within the analytic (such as unique IPs, unique users, etc.) are initial guidelines and should be customized based on the organization's user behavior and risk profile. Recognizing this behavior is vital for security operations centers (SOCs) as distributed password spraying represents a more complex form of traditional password spraying. Attackers distribute the source of their attempts to evade detection mechanisms that typically monitor for single-source IP anomalies. Prompt detection of such distributed activities is essential to thwart unauthorized access attempts, prevent account compromises, and mitigate the risk of further malicious activities within the organization's network. A true positive alert from this analytic suggests an active distributed password spraying attack against the organization's Azure AD tenant. A successful attack could result in unauthorized access, particularly to accounts with elevated privileges, leading to data breaches, privilege escalation, persistent threats, and lateral movement within the organization's infrastructure. search: ' `azure_monitor_aad` category=SignInLogs properties.status.errorCode=50126 properties.authenticationDetails{}.succeeded=false | rename properties.* as * | bucket span=5m _time | eval uniqueIPUserCombo = src_ip . "-" . user | stats dc(uniqueIPUserCombo) as uniqueIpUserCombinations, dc(user) as uniqueUsers, dc(src_ip) as uniqueIPs, dc(location.countryOrRegion) as uniqueCountries values(user) as users, values(src_ip) as ips, values(user_agent) as user_agents, values(location.countryOrRegion) as countries by _time - | where uniqueIpUserCombinations > 10 AND uniqueUsers > 10 AND uniqueIPs > 10 + | where uniqueIpUserCombinations > 20 AND uniqueUsers > 20 AND uniqueIPs > 20 | `azure_ad_multi_source_failed_authentications_spike_filter`' 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 SignInLogs log category. -known_false_positives: UPDATE_KNOWN_FALSE_POSITIVES + The thresholds set within the analytic (such as unique IPs, unique users, etc.) are initial guidelines and should be customized based on the organization's user behavior and risk profile. Security teams are encouraged to adjust these thresholds to optimize the balance between detecting genuine threats and minimizing false positives, ensuring the detection is tailored to their specific environment. +known_false_positives: This detection may yield false positives in scenarios where legitimate bulk sign-in activities occur, such as during company-wide system updates or when users are accessing resources from varying locations in a short time frame, such as in the case of VPNs or cloud services that rotate IP addresses. Filter as needed. references: - https://attack.mitre.org/techniques/T1110/003/ - https://docs.microsoft.com/en-us/security/compass/incident-response-playbook-password-spray @@ -30,7 +31,7 @@ tags: atomic_guid: [] confidence: 60 impact: 70 - message: UPDATE message + message: An anomalous multi source authentication spike ocurred at $_time$ mitre_attack_id: - T1586 - T1586.003 From 8c0c0575a98772cca17d37a927a52c5d6692c60f Mon Sep 17 00:00:00 2001 From: mvelazco Date: Thu, 9 Nov 2023 16:55:36 -0500 Subject: [PATCH 33/33] updating hunting query --- .../azure_ad_multi_source_failed_authentications_spike.yml | 5 ----- 1 file changed, 5 deletions(-) diff --git a/detections/cloud/azure_ad_multi_source_failed_authentications_spike.yml b/detections/cloud/azure_ad_multi_source_failed_authentications_spike.yml index fdd93d2ad1..a0b471a1f6 100644 --- a/detections/cloud/azure_ad_multi_source_failed_authentications_spike.yml +++ b/detections/cloud/azure_ad_multi_source_failed_authentications_spike.yml @@ -38,11 +38,6 @@ tags: - T1110 - T1110.003 - T1110.004 - observable: - - name: src_ip - type: IP Address - role: - - Attacker product: - Splunk Enterprise - Splunk Enterprise Security