diff --git a/.github/workflows/contentctl_test.yml b/.github/workflows/contentctl_test.yml
new file mode 100644
index 0000000000..7e01bb6c9a
--- /dev/null
+++ b/.github/workflows/contentctl_test.yml
@@ -0,0 +1,31 @@
+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: Check out the repository code
+        uses: actions/checkout@v3
+
+      - 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 run contentctl -p ../ validate
+            poetry run contentctl -p ../ test --mode changes --target_branch develop --test_branch TR_3232_azure_ad
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 46b843fadc..c392607b7b 100644
--- a/contentctl_test.yml
+++ b/contentctl_test.yml
@@ -1,4 +1,7 @@
-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
@@ -18,6 +21,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
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..3582f54f6a
--- /dev/null
+++ b/detections/cloud/azure_ad_block_user_consent_for_risky_apps_disabled.yml
@@ -0,0 +1,62 @@
+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: 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 * 
+ | 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: 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:
+  - Azure Active Directory Account Takeover
+  asset_type: Azure AD
+  confidence: 50
+  impact: 60
+  message: User $user$ disabled the BlockUserConsentForRiskyApps Azure AD setting.
+  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
+  - operationName
+  - properties.targetResources{}.modifiedProperties{}.displayName
+  - properties.targetResources{}.modifiedProperties{}.newValue
+  - user
+  - src_ip
+  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_device_code_authentication.yml b/detections/cloud/azure_ad_device_code_authentication.yml
new file mode 100644
index 0000000000..dcb5c8b1a1
--- /dev/null
+++ b/detections/cloud/azure_ad_device_code_authentication.yml
@@ -0,0 +1,74 @@
+name: Azure AD Device Code Authentication
+id: d68d8732-6f7e-4ee5-a6eb-737f2b990b91
+version: 1
+date: '2023-08-03'
+author: Mauricio Velazco, Gowthamaraj Rajendran,  Splunk
+status: production
+type: TTP
+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: '`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)`
+  | `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 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
+- 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: Device code requested for $user$ from $src_ip$
+  mitre_attack_id:
+  - T1528
+  - T1566
+  - T1566.002
+  observable:
+  - name: user
+    type: User
+    role:
+    - Victim
+  - name: src_ip
+    type: IP Address
+    role:
+    - Attacker
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  risk_score: 35
+  required_fields:
+  - _time
+  - category
+  - user
+  - properties.authenticationProtocol
+  - properties.ipAddress
+  - properties.status.additionalDetails
+  - 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/T1528/device_code_authentication/azure-audit.log
+    source: Azure AD
+    sourcetype: azure:monitor:aad
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..a0b471a1f6
--- /dev/null
+++ b/detections/cloud/azure_ad_multi_source_failed_authentications_spike.yml
@@ -0,0 +1,60 @@
+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: 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 > 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.
+  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
+- 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: An anomalous multi source authentication spike ocurred at $_time$
+  mitre_attack_id:
+  - T1586
+  - T1586.003
+  - T1110
+  - T1110.003
+  - T1110.004
+  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
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..a40bfe0408
--- /dev/null
+++ b/detections/cloud/azure_ad_multiple_appids_and_useragents_authentication_spike.yml
@@ -0,0 +1,59 @@
+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: []
+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: ' `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
+   | 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: 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:
+- 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: Azure AD Tenant
+  confidence: 80
+  impact: 60
+  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:
+  - name: user
+    type: User
+    role:
+    - Victim
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  risk_score: 48
+  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
+  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/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..5900e68ae6
--- /dev/null
+++ b/detections/cloud/azure_ad_multiple_denied_mfa_requests_for_user.yml
@@ -0,0 +1,65 @@
+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 operationName="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: 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/
+- 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
+  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
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..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
@@ -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,24 +8,26 @@ 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
   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: ' `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
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..6ff1d2a24a
--- /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)(?<new_method_type>\"MethodType\")"
+ | rex field=oldvalue max_match=0 "(?i)(?<old_method_type>\"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
+
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..84bd5c2b0b
--- /dev/null
+++ b/detections/cloud/azure_ad_oauth_application_consent_granted_by_user.yml
@@ -0,0 +1,63 @@
+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: []
+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 * 
+  | 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: (?<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: 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: 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:
+- 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
+  confidence: 60
+  impact: 60
+  message: User $user$ consented an OAuth application.
+  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.targetResources{}.modifiedProperties{}.displayName
+  - 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/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
new file mode 100644
index 0000000000..0f621ddf20
--- /dev/null
+++ b/detections/cloud/azure_ad_tenant_wide_admin_consent_granted.yml
@@ -0,0 +1,62 @@
+name: Azure AD Tenant Wide Admin Consent Granted
+id: dc02c0ee-6ac0-4c7f-87ba-8ce43a4e4418
+version: 2
+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: >- 
+ `azure_monitor_aad` operationName="Consent to application"
+ | eval new_field=mvindex('properties.targetResources{}.modifiedProperties{}.newValue', 4)
+ | rename properties.* as * 
+ | rex field=new_field "ConsentType: (?<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.
+  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/
+- 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:
+  - Azure Active Directory Persistence
+  asset_type: Azure AD
+  confidence: 50
+  impact: 90
+  message: Administrator $user$ consented an OAuth application for the tenant.
+  mitre_attack_id:
+  - T1098
+  - T1098.003
+  observable:
+  - name: user
+    type: User
+    role:
+    - Attacker
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  risk_score: 45
+  required_fields:
+  - _time
+  - operationName
+  - user
+  - properties.targetResources{}.modifiedProperties{}.newValue
+  - 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: Azure AD
+    sourcetype: azure:monitor:aad
\ No newline at end of file
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..8d63e5c709
--- /dev/null
+++ b/detections/cloud/azure_ad_user_consent_blocked_for_risky_application.yml
@@ -0,0 +1,66 @@
+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: >-
+  `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)
+  | 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: (?<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: 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/
+- 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
+  - operationName
+  - properties.result
+  - properties.targetResources{}.modifiedProperties{}.displayName
+  - properties.targetResources{}.modifiedProperties{}.newValue
+  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
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..039f7e5d33
--- /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: 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/
+- 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
+  confidence: 60
+  impact: 60
+  message: User $user$ denied consent for an OAuth application.
+  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
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