From cf4b6e6e1e8395debde9a1669cfa7de52fd553bc Mon Sep 17 00:00:00 2001 From: Jonhnathan Date: Fri, 22 Jul 2022 14:32:42 -0300 Subject: [PATCH] [Security Content] Add Investigation Guides - Cloud - 2 (#2124) * [Security Content] Add Investigation Guides - Cloud - 2 * Replace config/setup * Applies suggestions from review * Update credential_access_aws_iam_assume_role_brute_force.toml * Apply suggestions from code review * Update credential_access_aws_iam_assume_role_brute_force.toml * Apply suggestions from code review Co-authored-by: nastasha-solomon <79124755+nastasha-solomon@users.noreply.github.com> Co-authored-by: nastasha-solomon <79124755+nastasha-solomon@users.noreply.github.com> (cherry picked from commit 7ddae4b4930df250d1191466f5cf66786d1b550e) --- ...ccess_aws_iam_assume_role_brute_force.toml | 60 +++++++++++++++++- ...ial_access_iam_user_addition_to_group.toml | 51 +++++++++++++++- ..._access_secretsmanager_getsecretvalue.toml | 2 +- ..._evasion_config_service_rule_deletion.toml | 2 +- ...ltration_ec2_snapshot_change_activity.toml | 2 +- ...impact_cloudwatch_log_stream_deletion.toml | 2 +- .../aws/impact_iam_deactivate_mfa_device.toml | 53 +++++++++++++++- .../initial_access_via_system_manager.toml | 2 +- .../ml_cloudtrail_error_message_spike.toml | 2 +- .../aws/ml_cloudtrail_rare_error_code.toml | 2 +- .../ml_cloudtrail_rare_method_by_city.toml | 2 +- .../ml_cloudtrail_rare_method_by_country.toml | 2 +- .../ml_cloudtrail_rare_method_by_user.toml | 2 +- ...ege_escalation_updateassumerolepolicy.toml | 56 ++++++++++++++++- ...sion_azure_service_principal_addition.toml | 59 ++++++++++++++++-- ...ure_active_directory_high_risk_signin.toml | 56 ++++++++++++++++- ..._high_risk_signin_atrisk_or_confirmed.toml | 52 +++++++++++++++- ...re_active_directory_powershell_signin.toml | 54 +++++++++++++++- ...tack_via_azure_registered_application.toml | 61 +++++++++++++++++-- ...ged_identity_management_role_modified.toml | 54 +++++++++++++++- 20 files changed, 541 insertions(+), 35 deletions(-) diff --git a/rules/integrations/aws/credential_access_aws_iam_assume_role_brute_force.toml b/rules/integrations/aws/credential_access_aws_iam_assume_role_brute_force.toml index 665bd5207..a65ec7316 100644 --- a/rules/integrations/aws/credential_access_aws_iam_assume_role_brute_force.toml +++ b/rules/integrations/aws/credential_access_aws_iam_assume_role_brute_force.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2020/07/16" maturity = "production" -updated_date = "2021/07/20" +updated_date = "2022/07/19" integration = "aws" [rule] @@ -16,7 +16,63 @@ index = ["filebeat-*", "logs-aws*"] language = "kuery" license = "Elastic License v2" name = "AWS IAM Brute Force of Assume Role Policy" -note = """## Setup +note = """## Triage and analysis + +### Investigating AWS IAM Brute Force of Assume Role Policy + +An IAM role is an IAM identity that you can create in your account that has specific permissions. An IAM role is similar +to an IAM user, in that it is an AWS identity with permission policies that determine what the identity can and cannot +do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone +who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated +with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session. + +Attackers may attempt to enumerate IAM roles in order to determine if a role exists before attempting to assume or +hijack the discovered role. + +#### Possible investigation steps + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Verify if the `RoleName` parameter contains a unique value in all requests or if the activity is potentially a brute +force attack. +- Verify if the user account successfully updated a trust policy in the last 24 hours. +- Examine whether this role existed in the environment by looking for past occurrences in your logs. +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account and resource owners and confirm whether they are aware of this activity. +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal +time of day? +- Examine the account's commands, API calls, and data management actions in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, +and data accessed by the account in the last 24 hours. + +### False positive analysis + +- Verify the roles targeted in the failed attempts, and whether the subject role previously existed in the environment. +If only one role was targeted in the requests and that role previously existed, it may be a false positive, since +automations can continue targeting roles that existed in the environment in the past and cause false positives (FPs). + +### Response and remediation + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are +identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with +your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other +IAM users. +- Consider enabling multi-factor authentication for users. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the +mean time to respond (MTTR). + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/credential_access_iam_user_addition_to_group.toml b/rules/integrations/aws/credential_access_iam_user_addition_to_group.toml index 9739cf4c3..01b173a9d 100644 --- a/rules/integrations/aws/credential_access_iam_user_addition_to_group.toml +++ b/rules/integrations/aws/credential_access_iam_user_addition_to_group.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2020/06/04" maturity = "production" -updated_date = "2021/07/20" +updated_date = "2022/07/19" integration = "aws" [rule] @@ -21,7 +21,54 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS IAM User Addition to Group" -note = """## Setup +note = """## Triage and analysis + +### Investigating AWS IAM User Addition to Group + +AWS Identity and Access Management (IAM) provides fine-grained access control across all of AWS. With IAM, you can specify +who can access which services and resources, and under which conditions. With IAM policies, you manage permissions to +your workforce and systems to ensure least-privilege permissions. + +This rule looks for the addition of users to a specified user group. + +#### Possible investigation steps + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account and resource owners and confirm whether they are aware of this activity. +- Check if this operation was approved and performed according to the organization's change management policy. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, +and data accessed by the account in the last 24 hours. + +### False positive analysis + +- False positives may occur due to the intended usage of the service. Tuning is needed in order to have higher +confidence. Consider adding exceptions — preferably with a combination of user agent and IP address conditions — to +reduce noise from onboarding processes and administrator activities. + +### Response and remediation + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are +identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with +your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other +IAM users. +- Consider enabling multi-factor authentication for users. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the +mean time to respond (MTTR). + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddUserToGroup.html"] diff --git a/rules/integrations/aws/credential_access_secretsmanager_getsecretvalue.toml b/rules/integrations/aws/credential_access_secretsmanager_getsecretvalue.toml index 6e8938883..50ad221fd 100644 --- a/rules/integrations/aws/credential_access_secretsmanager_getsecretvalue.toml +++ b/rules/integrations/aws/credential_access_secretsmanager_getsecretvalue.toml @@ -63,7 +63,7 @@ confidence. Consider adding exceptions — preferably with a combination of user - Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: - Identify the account role in the cloud environment. - Assess the criticality of affected services and servers. - - Work with your IT team to identify the impact on users. + - Work with your IT team to identify and minimize the impact on users. - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. - Identify any regulatory or legal ramifications related to this activity. - Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are diff --git a/rules/integrations/aws/defense_evasion_config_service_rule_deletion.toml b/rules/integrations/aws/defense_evasion_config_service_rule_deletion.toml index 803a747d0..0f38bfd56 100644 --- a/rules/integrations/aws/defense_evasion_config_service_rule_deletion.toml +++ b/rules/integrations/aws/defense_evasion_config_service_rule_deletion.toml @@ -64,7 +64,7 @@ combination of user and IP address conditions. - Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: - Identify the account role in the cloud environment. - Assess the criticality of affected services and servers. - - Work with your IT team to identify the impact on users. + - Work with your IT team to identify and minimize the impact on users. - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. - Identify any regulatory or legal ramifications related to this activity. - Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are diff --git a/rules/integrations/aws/exfiltration_ec2_snapshot_change_activity.toml b/rules/integrations/aws/exfiltration_ec2_snapshot_change_activity.toml index 3bc4f08aa..876ec8bf8 100644 --- a/rules/integrations/aws/exfiltration_ec2_snapshot_change_activity.toml +++ b/rules/integrations/aws/exfiltration_ec2_snapshot_change_activity.toml @@ -63,7 +63,7 @@ combination of user and IP address conditions. - Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: - Identify the account role in the cloud environment. - Assess the criticality of affected services and servers. - - Work with your IT team to identify the impact on users. + - Work with your IT team to identify and minimize the impact on users. - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. - Identify any regulatory or legal ramifications related to this activity. - Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are diff --git a/rules/integrations/aws/impact_cloudwatch_log_stream_deletion.toml b/rules/integrations/aws/impact_cloudwatch_log_stream_deletion.toml index 22844bc38..e5eee33b4 100644 --- a/rules/integrations/aws/impact_cloudwatch_log_stream_deletion.toml +++ b/rules/integrations/aws/impact_cloudwatch_log_stream_deletion.toml @@ -66,7 +66,7 @@ combination of user and IP address conditions. - Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: - Identify the account role in the cloud environment. - Assess the criticality of affected services and servers. - - Work with your IT team to identify the impact on users. + - Work with your IT team to identify and minimize the impact on users. - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. - Identify any regulatory or legal ramifications related to this activity. - Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are diff --git a/rules/integrations/aws/impact_iam_deactivate_mfa_device.toml b/rules/integrations/aws/impact_iam_deactivate_mfa_device.toml index c661983dc..3a74b4354 100644 --- a/rules/integrations/aws/impact_iam_deactivate_mfa_device.toml +++ b/rules/integrations/aws/impact_iam_deactivate_mfa_device.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2020/05/26" maturity = "production" -updated_date = "2021/07/20" +updated_date = "2022/07/19" integration = "aws" [rule] @@ -24,7 +24,56 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS IAM Deactivation of MFA Device" -note = """## Setup +note = """## Triage and analysis + +### Investigating AWS IAM Deactivation of MFA Device + +Multi-factor authentication (MFA) in AWS is a simple best practice that adds an extra layer of protection on top of your +user name and password. With MFA enabled, when a user signs in to an AWS Management Console, they will be prompted for +their user name and password (the first factor—what they know), as well as for an authentication code from their AWS MFA +device (the second factor—what they have). Taken together, these multiple factors provide increased security for your +AWS account settings and resources. + +For more information about using MFA in AWS, access the [official documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html). + +This rule looks for the deactivation or deletion of AWS MFA devices. These modifications weaken account security and can +lead to the compromise of accounts and other assets. + +#### Possible investigation steps + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account and resource owners and confirm whether they are aware of this activity. +- Check if this operation was approved and performed according to the organization's change management policy. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, +and data accessed by the account in the last 24 hours. + +### False positive analysis + +- While this activity can be done by administrators, all users must use MFA. The security team should address any +potential benign true positive (B-TP), as this configuration can risk the user and domain. + +### Response and remediation + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are +identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with +your IT teams to minimize the impact on business operations during these actions. +- Reactivate multi-factor authentication for the user. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the +mean time to respond (MTTR). + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/initial_access_via_system_manager.toml b/rules/integrations/aws/initial_access_via_system_manager.toml index cc0a8254e..1ebe340da 100644 --- a/rules/integrations/aws/initial_access_via_system_manager.toml +++ b/rules/integrations/aws/initial_access_via_system_manager.toml @@ -65,7 +65,7 @@ combination of user and IP address conditions. - Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: - Identify the account role in the cloud environment. - Assess the criticality of affected services and servers. - - Work with your IT team to identify the impact on users. + - Work with your IT team to identify and minimize the impact on users. - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. - Identify any regulatory or legal ramifications related to this activity. - Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are diff --git a/rules/integrations/aws/ml_cloudtrail_error_message_spike.toml b/rules/integrations/aws/ml_cloudtrail_error_message_spike.toml index c0cc4ed3c..e4cb8e8ea 100644 --- a/rules/integrations/aws/ml_cloudtrail_error_message_spike.toml +++ b/rules/integrations/aws/ml_cloudtrail_error_message_spike.toml @@ -76,7 +76,7 @@ it might be part of a housekeeping or maintenance process. You can find the comm - Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: - Identify the account role in the cloud environment. - Assess the criticality of affected services and servers. - - Work with your IT team to identify the impact on users. + - Work with your IT team to identify and minimize the impact on users. - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. - Identify any regulatory or legal ramifications related to this activity. - Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are diff --git a/rules/integrations/aws/ml_cloudtrail_rare_error_code.toml b/rules/integrations/aws/ml_cloudtrail_rare_error_code.toml index 509a02d65..8e9904cec 100644 --- a/rules/integrations/aws/ml_cloudtrail_rare_error_code.toml +++ b/rules/integrations/aws/ml_cloudtrail_rare_error_code.toml @@ -79,7 +79,7 @@ it might be part of a housekeeping or maintenance process. You can find the comm - Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: - Identify the account role in the cloud environment. - Assess the criticality of affected services and servers. - - Work with your IT team to identify the impact on users. + - Work with your IT team to identify and minimize the impact on users. - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. - Identify any regulatory or legal ramifications related to this activity. - Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are diff --git a/rules/integrations/aws/ml_cloudtrail_rare_method_by_city.toml b/rules/integrations/aws/ml_cloudtrail_rare_method_by_city.toml index a0ec5d064..a1a1cff48 100644 --- a/rules/integrations/aws/ml_cloudtrail_rare_method_by_city.toml +++ b/rules/integrations/aws/ml_cloudtrail_rare_method_by_city.toml @@ -81,7 +81,7 @@ it might be part of a housekeeping or maintenance process. You can find the comm - Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: - Identify the account role in the cloud environment. - Assess the criticality of affected services and servers. - - Work with your IT team to identify the impact on users. + - Work with your IT team to identify and minimize the impact on users. - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. - Identify any regulatory or legal ramifications related to this activity. - Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are diff --git a/rules/integrations/aws/ml_cloudtrail_rare_method_by_country.toml b/rules/integrations/aws/ml_cloudtrail_rare_method_by_country.toml index 435dad45d..cf997be4a 100644 --- a/rules/integrations/aws/ml_cloudtrail_rare_method_by_country.toml +++ b/rules/integrations/aws/ml_cloudtrail_rare_method_by_country.toml @@ -81,7 +81,7 @@ it might be part of a housekeeping or maintenance process. You can find the comm - Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: - Identify the account role in the cloud environment. - Assess the criticality of affected services and servers. - - Work with your IT team to identify the impact on users. + - Work with your IT team to identify and minimize the impact on users. - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. - Identify any regulatory or legal ramifications related to this activity. - Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are diff --git a/rules/integrations/aws/ml_cloudtrail_rare_method_by_user.toml b/rules/integrations/aws/ml_cloudtrail_rare_method_by_user.toml index 2744b8b9f..35988790a 100644 --- a/rules/integrations/aws/ml_cloudtrail_rare_method_by_user.toml +++ b/rules/integrations/aws/ml_cloudtrail_rare_method_by_user.toml @@ -79,7 +79,7 @@ it might be part of a housekeeping or maintenance process. You can find the comm - Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: - Identify the account role in the cloud environment. - Assess the criticality of affected services and servers. - - Work with your IT team to identify the impact on users. + - Work with your IT team to identify and minimize the impact on users. - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. - Identify any regulatory or legal ramifications related to this activity. - Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are diff --git a/rules/integrations/aws/privilege_escalation_updateassumerolepolicy.toml b/rules/integrations/aws/privilege_escalation_updateassumerolepolicy.toml index d01743d79..82b339e27 100644 --- a/rules/integrations/aws/privilege_escalation_updateassumerolepolicy.toml +++ b/rules/integrations/aws/privilege_escalation_updateassumerolepolicy.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2020/07/06" maturity = "production" -updated_date = "2021/07/20" +updated_date = "2022/07/19" integration = "aws" [rule] @@ -23,7 +23,59 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS IAM Assume Role Policy Update" -note = """## Setup +note = """## Triage and analysis + +### Investigating AWS IAM Assume Role Policy Update + +An IAM role is an IAM identity that you can create in your account that has specific permissions. An IAM role is similar +to an IAM user, in that it is an AWS identity with permission policies that determine what the identity can and cannot +do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone +who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated +with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session. + +The role trust policy is a JSON document in which you define the principals you trust to assume the role. This policy is +a required resource-based policy that is attached to a role in IAM. An attacker may attempt to modify this policy by +using the `UpdateAssumeRolePolicy` API action to gain the privileges of that role. + +#### Possible investigation steps + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account and resource owners and confirm whether they are aware of this activity. +- Check if this operation was approved and performed according to the organization's change management policy. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, +and data accessed by the account in the last 24 hours. + +### False positive analysis + +- False positives may occur due to the intended usage of the service. Tuning is needed in order to have higher +confidence. Consider adding exceptions — preferably with a combination of the user agent and user ID conditions — to +cover administrator activities and infrastructure as code tooling. + +### Response and remediation + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Use AWS [policy versioning](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-versioning.html) to restore the trust policy to the desired state. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are +identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with +your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other +IAM users. +- Consider enabling multi-factor authentication for users. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the +mean time to respond (MTTR). + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://labs.bishopfox.com/tech-blog/5-privesc-attack-vectors-in-aws"] diff --git a/rules/integrations/azure/defense_evasion_azure_service_principal_addition.toml b/rules/integrations/azure/defense_evasion_azure_service_principal_addition.toml index df3048adf..4fba20ea4 100644 --- a/rules/integrations/azure/defense_evasion_azure_service_principal_addition.toml +++ b/rules/integrations/azure/defense_evasion_azure_service_principal_addition.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2020/12/14" maturity = "production" -updated_date = "2021/07/20" +updated_date = "2022/07/19" integration = "azure" [rule] @@ -24,16 +24,67 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Service Principal Addition" -note = """## Setup +note = """## Triage and analysis + +### Investigating Azure Service Principal Addition + +Service Principals are identities used by applications, services, and automation tools to access specific resources. +They grant specific access based on the assigned API permissions. Most organizations that work a lot with Azure AD make +use of service principals. Whenever an application is registered, it automatically creates an application object and a +service principal in an Azure AD tenant. + +This rule looks for the addition of service principals. This behavior may enable attackers to impersonate legitimate +service principals to camouflage their activities among noisy automations/apps. + +#### Possible investigation steps + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the source IP address and geolocation for the user who issued the command. Do they look normal for the user? +- Consider the time of day. If the user is a human, not a program or script, did the activity take place during a normal +time of day? +- Check if this operation was approved and performed according to the organization's change management policy. +- Contact the account owner and confirm whether they are aware of this activity. +- Examine the account's commands, API calls, and data management actions in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, +and data accessed by the account in the last 24 hours. + +### False positive analysis + +If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a +combination of user and device conditions. + +### Response and remediation + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are +identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with +your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other +IAM users. +- Consider enabling multi-factor authentication for users. +- Follow security best practices [outlined](https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices) by Microsoft. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the +mean time to respond (MTTR). + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ "https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/", "https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal", ] -risk_score = 47 +risk_score = 21 rule_id = "60b6b72f-0fbc-47e7-9895-9ba7627a8b50" -severity = "medium" +severity = "low" tags = ["Elastic", "Cloud", "Azure", "Continuous Monitoring", "SecOps", "Identity and Access"] timestamp_override = "event.ingested" type = "query" diff --git a/rules/integrations/azure/initial_access_azure_active_directory_high_risk_signin.toml b/rules/integrations/azure/initial_access_azure_active_directory_high_risk_signin.toml index 4451d2c34..eec7eee27 100644 --- a/rules/integrations/azure/initial_access_azure_active_directory_high_risk_signin.toml +++ b/rules/integrations/azure/initial_access_azure_active_directory_high_risk_signin.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2021/01/04" maturity = "production" -updated_date = "2021/08/30" +updated_date = "2022/07/19" integration = "azure" [rule] @@ -17,9 +17,59 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Active Directory High Risk Sign-in" -note = """## Setup +note = """## Triage and analysis -The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" +### Investigating Azure Active Directory High Risk Sign-in + +Microsoft Identity Protection is an Azure AD security tool that detects various types of identity risks and attacks. + +This rule identifies events produced by Microsoft Identity Protection with high risk levels or high aggregated risk level. + +#### Possible investigation steps + +- Identify the Risk Detection that triggered the event. A list with descriptions can be found [here](https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks#risk-types-and-detection). +- Identify the user account involved and validate whether the suspicious activity is normal for that user. + - Consider the source IP address and geolocation for the involved user account. Do they look normal? + - Consider the device used to sign in. Is it registered and compliant? +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account owner and confirm whether they are aware of this activity. +- Check if this operation was approved and performed according to the organization's change management policy. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, +and data accessed by the account in the last 24 hours. + +### False positive analysis + +If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a +combination of user and device conditions. + +### Response and remediation + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are +identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with +your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other +IAM users. +- Consider enabling multi-factor authentication for users. +- Follow security best practices [outlined](https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices) by Microsoft. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the +mean time to respond (MTTR). + +## Setup + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +Note that details for `azure.signinlogs.properties.risk_level_during_signin` and `azure.signinlogs.properties.risk_level_aggregated` +are only available for Azure AD Premium P2 customers. All other customers will be returned `hidden`. +""" references = [ "https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-risk", "https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/overview-identity-protection", diff --git a/rules/integrations/azure/initial_access_azure_active_directory_high_risk_signin_atrisk_or_confirmed.toml b/rules/integrations/azure/initial_access_azure_active_directory_high_risk_signin_atrisk_or_confirmed.toml index a6abe98e9..350583d23 100644 --- a/rules/integrations/azure/initial_access_azure_active_directory_high_risk_signin_atrisk_or_confirmed.toml +++ b/rules/integrations/azure/initial_access_azure_active_directory_high_risk_signin_atrisk_or_confirmed.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2021/10/18" maturity = "production" -updated_date = "2021/10/18" +updated_date = "2022/07/19" integration = "azure" [rule] @@ -15,13 +15,61 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Active Directory High Risk User Sign-in Heuristic" -note = """## Setup +note = """## Triage and analysis + +### Investigating Azure Active Directory High Risk User Sign-in Heuristic + +Microsoft Identity Protection is an Azure AD security tool that detects various types of identity risks and attacks. + +This rule identifies events produced by the Microsoft Identity Protection with a risk state equal to `confirmedCompromised` +or `atRisk`. + +#### Possible investigation steps + +- Identify the Risk Detection that triggered the event. A list with descriptions can be found [here](https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks#risk-types-and-detection). +- Identify the user account involved and validate whether the suspicious activity is normal for that user. + - Consider the source IP address and geolocation for the involved user account. Do they look normal? + - Consider the device used to sign in. Is it registered and compliant? +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account owner and confirm whether they are aware of this activity. +- Check if this operation was approved and performed according to the organization's change management policy. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, +and data accessed by the account in the last 24 hours. + +### False positive analysis + +If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a +combination of user and device conditions. + +### Response and remediation + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are +identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with +your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other +IAM users. +- Consider enabling multi-factor authentication for users. +- Follow security best practices [outlined](https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices) by Microsoft. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the +mean time to respond (MTTR). + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ "https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema", "https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/overview-identity-protection", "https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-investigate-risk", + "https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-investigate-risk#investigation-framework", ] risk_score = 47 rule_id = "26edba02-6979-4bce-920a-70b080a7be81" diff --git a/rules/integrations/azure/initial_access_azure_active_directory_powershell_signin.toml b/rules/integrations/azure/initial_access_azure_active_directory_powershell_signin.toml index 34a07cd54..f8a0f1717 100644 --- a/rules/integrations/azure/initial_access_azure_active_directory_powershell_signin.toml +++ b/rules/integrations/azure/initial_access_azure_active_directory_powershell_signin.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2020/12/14" maturity = "production" -updated_date = "2021/07/20" +updated_date = "2022/07/19" integration = "azure" [rule] @@ -22,7 +22,57 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Active Directory PowerShell Sign-in" -note = """## Setup +note = """## Triage and analysis + +### Investigating Azure Active Directory PowerShell Sign-in + +Azure Active Directory PowerShell for Graph (Azure AD PowerShell) is a module IT professionals commonly use to manage +their Azure Active Directory. The cmdlets in the Azure AD PowerShell module enable you to retrieve data from the +directory, create new objects in the directory, update existing objects, remove objects, as well as configure the +directory and its features. + +This rule identifies sign-ins that use the Azure Active Directory PowerShell module, which can indicate unauthorized +access if done outside of IT or engineering. + +#### Possible investigation steps + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Evaluate whether the user needs to access Azure AD using PowerShell to complete its tasks. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the source IP address and geolocation for the involved user account. Do they look normal? +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate suspicious actions taken by the user using the module, for example, modifications in security settings +that weakens the security policy, persistence-related tasks, and data access. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, +and data accessed by the account in the last 24 hours. + +### False positive analysis + +- If this activity is expected and noisy in your environment, consider adding IT, Engineering, and other authorized users +as exceptions — preferably with a combination of user and device conditions. + +### Response and remediation + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are +identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with +your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other +IAM users. +- Consider enabling multi-factor authentication for users. +- Follow security best practices [outlined](https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices) by Microsoft. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the +mean time to respond (MTTR). + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/azure/initial_access_consent_grant_attack_via_azure_registered_application.toml b/rules/integrations/azure/initial_access_consent_grant_attack_via_azure_registered_application.toml index 2e614c095..a23b24d8a 100644 --- a/rules/integrations/azure/initial_access_consent_grant_attack_via_azure_registered_application.toml +++ b/rules/integrations/azure/initial_access_consent_grant_attack_via_azure_registered_application.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2020/09/01" maturity = "production" -updated_date = "2021/07/20" +updated_date = "2022/07/19" integration = "azure" [rule] @@ -18,16 +18,69 @@ license = "Elastic License v2" name = "Possible Consent Grant Attack via Azure-Registered Application" note = """## Triage and analysis -- In a consent grant attack, an attacker tricks an end user into granting a malicious application consent to access their data, usually via a phishing attack. After the malicious application has been granted consent, it has account-level access to data without the need for an organizational account. -- Normal remediation steps, like resetting passwords for breached accounts or requiring Multi-Factor Authentication (MFA) on accounts, are not effective against this type of attack, since these are third-party applications and are external to the organization. -- Security analysts should review the list of trusted applications for any suspicious items. +### Investigating Possible Consent Grant Attack via Azure-Registered Application +In an illicit consent grant attack, the attacker creates an Azure-registered application that requests access to data +such as contact information, email, or documents. The attacker then tricks an end user into granting that application +consent to access their data either through a phishing attack, or by injecting illicit code into a trusted website. +After the illicit application has been granted consent, it has account-level access to data without the need for an +organizational account. Normal remediation steps like resetting passwords for breached accounts or requiring multi-factor +authentication (MFA) on accounts are not effective against this type of attack, since these are third-party applications +and are external to the organization. + +Official Microsoft guidance for detecting and remediating this attack can be found [here](https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants). + +#### Possible investigation steps + +- From the Azure AD portal, Review the application that was granted permissions: + - Click on the `Review permissions` button on the `Permissions` blade of the application. + - An app should require only permissions related to the app's purpose. If that's not the case, the app might be risky. + - Apps that require high privileges or admin consent are more likely to be risky. +- Investigate the app and the publisher. The following characteristics can indicate suspicious apps: + - A low number of downloads. + - Low rating or score or bad comments. + - Apps with a suspicious publisher or website. + - Apps whose last update is not recent. This might indicate an app that is no longer supported. +- Export and examine the [Oauth app auditing](https://docs.microsoft.com/en-us/defender-cloud-apps/manage-app-permissions#oauth-app-auditing) to identify users affected. + +### False positive analysis + +- This mechanism can be used legitimately. Malicious applications abuse the same workflow used by legitimate apps. +Thus, analysts must review each app consent to ensure that only desired apps are granted access. + +### Response and remediation + +- Initiate the incident response process based on the outcome of the triage. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Disable the malicious application to stop user access and the application access to your data. +- Revoke the application Oauth consent grant. The `Remove-AzureADOAuth2PermissionGrant` cmdlet can be used to complete +this task. +- Remove the service principal application role assignment. The `Remove-AzureADServiceAppRoleAssignment` cmdlet can be +used to complete this task. +- Revoke the refresh token for all users assigned to the application. Azure provides a [playbook](https://github.com/Azure/Azure-Sentinel/tree/master/Playbooks/Revoke-AADSignInSessions) for this task. +- [Report](https://docs.microsoft.com/en-us/defender-cloud-apps/manage-app-permissions#send-feedback) the application as malicious to Microsoft. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are +identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with +your IT teams to minimize the impact on business operations during these actions. +- Investigate the potential for data compromise from the user's email and file sharing services. Activate your Data Loss +incident response playbook. +- Disable the permission for a user to set consent permission on their behalf. + - Enable the [Admin consent request](https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/configure-admin-consent-workflow) feature. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the +mean time to respond (MTTR). ## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ "https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants?view=o365-worldwide", + "https://www.cloud-architekt.net/detection-and-mitigation-consent-grant-attacks-azuread/", + "https://docs.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth#how-to-detect-risky-oauth-apps", ] risk_score = 47 rule_id = "1c6a8c7a-5cb6-4a82-ba27-d5a5b8a40a38" diff --git a/rules/integrations/azure/persistence_azure_privileged_identity_management_role_modified.toml b/rules/integrations/azure/persistence_azure_privileged_identity_management_role_modified.toml index a7cea2de7..3fc79445b 100644 --- a/rules/integrations/azure/persistence_azure_privileged_identity_management_role_modified.toml +++ b/rules/integrations/azure/persistence_azure_privileged_identity_management_role_modified.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2020/09/01" maturity = "production" -updated_date = "2021/07/20" +updated_date = "2022/07/19" integration = "azure" [rule] @@ -17,7 +17,57 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Privilege Identity Management Role Modified" -note = """## Setup +note = """## Triage and analysis + +### Investigating Azure Privilege Identity Management Role Modified + +Azure Active Directory (AD) Privileged Identity Management (PIM) is a service that enables you to manage, control, and +monitor access to important resources in an organization. PIM can be used to manage the built-in Azure resource roles +such as Global Administrator and Application Administrator. + +This rule identifies the update of PIM role settings, which can indicate that an attacker has already gained enough +access to modify role assignment settings. + +#### Possible investigation steps + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the source IP address and geolocation for the user who issued the command. Do they look normal for the user? +- Consider the time of day. If the user is a human, not a program or script, did the activity take place during a normal +time of day? +- Check if this operation was approved and performed according to the organization's change management policy. +- Contact the account owner and confirm whether they are aware of this activity. +- Examine the account's commands, API calls, and data management actions in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, +and data accessed by the account in the last 24 hours. + +### False positive analysis + +- If this activity didn't follow your organization's change management policies, it should be reviewed by the security team. + +### Response and remediation + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are +identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with +your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other +IAM users. +- Restore the PIM roles to the desired state. +- Consider enabling multi-factor authentication for users. +- Follow security best practices [outlined](https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices) by Microsoft. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the +mean time to respond (MTTR). + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [