Skip to content

Commit

Permalink
Fix observable issues, unicode characters,
Browse files Browse the repository at this point in the history
and newline issues in detections.
  • Loading branch information
pyth0n1c committed Nov 8, 2023
1 parent 96d7006 commit 51a3b86
Show file tree
Hide file tree
Showing 6 changed files with 9 additions and 9 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Expand All @@ -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 changes 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/
Expand Down
6 changes: 3 additions & 3 deletions detections/cloud/azure_ad_device_code_authentication.yml
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
2 changes: 1 addition & 1 deletion detections/cloud/azure_ad_new_mfa_method_registered.yml
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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 *
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Expand Down

0 comments on commit 51a3b86

Please sign in to comment.