From 91c00fd44264e9382add4f84232de8ba8769c68b Mon Sep 17 00:00:00 2001 From: Jonhnathan Date: Wed, 27 Jul 2022 15:40:09 -0300 Subject: [PATCH] [Security Content] Add Investigation Guides - Cloud - 3 (#2132) * [Security Content] Add Investigation Guides - Cloud - 3 * Apply suggestions from code review Co-authored-by: Joe Peeples * Update rules/integrations/aws/defense_evasion_cloudtrail_logging_suspended.toml * update dates * Apply suggestions from review Co-authored-by: Joe Peeples --- ...se_evasion_cloudtrail_logging_deleted.toml | 61 +++++++++++++++++- ..._evasion_cloudtrail_logging_suspended.toml | 61 +++++++++++++++++- ...nse_evasion_cloudwatch_alarm_deletion.toml | 61 +++++++++++++++++- ...defense_evasion_ec2_flow_log_deletion.toml | 60 +++++++++++++++++- .../impact_cloudtrail_logging_updated.toml | 61 +++++++++++++++++- .../impact_cloudwatch_log_group_deletion.toml | 63 ++++++++++++++++++- .../initial_access_console_login_root.toml | 50 +++++++++++++-- ...ege_escalation_root_login_without_mfa.toml | 54 +++++++++++++++- ...rsistence_mfa_disabled_for_azure_user.toml | 54 +++++++++++++++- ...le_workspace_mfa_enforcement_disabled.toml | 54 +++++++++++++++- 10 files changed, 556 insertions(+), 23 deletions(-) diff --git a/rules/integrations/aws/defense_evasion_cloudtrail_logging_deleted.toml b/rules/integrations/aws/defense_evasion_cloudtrail_logging_deleted.toml index 702730aa6..41bacd7e4 100644 --- a/rules/integrations/aws/defense_evasion_cloudtrail_logging_deleted.toml +++ b/rules/integrations/aws/defense_evasion_cloudtrail_logging_deleted.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2020/05/26" maturity = "production" -updated_date = "2021/07/20" +updated_date = "2022/07/22" integration = "aws" [rule] @@ -20,7 +20,64 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS CloudTrail Log Deleted" -note = """## Setup +note = """## Triage and analysis + +### Investigating AWS CloudTrail Log Deleted + +Amazon CloudTrail is a service that enables governance, compliance, operational auditing, and risk auditing of your +Amazon Web Services account. With CloudTrail, you can log, continuously monitor, and retain account activity related to +actions across your Amazon Web Services infrastructure. CloudTrail provides event history of your Amazon Web Services +account activity, including actions taken through the Amazon Management Console, Amazon SDKs, command line tools, and +other Amazon Web Services services. This event history simplifies security analysis, resource change tracking, and +troubleshooting. + +This rule identifies the deletion of an AWS log trail using the API `DeleteTrail` action. Attackers can do this to +cover their tracks and impact security monitoring that relies on this source. + +#### 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. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the user? + - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source + IP from an EC2 instance that's not under your control? + - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? + Are there any other alerts or signs of suspicious activity involving this instance? +- Investigate the deleted log trail's criticality and whether the responsible team is aware of the deletion. +- 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 IP address 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. +- 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. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify 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/defense_evasion_cloudtrail_logging_suspended.toml b/rules/integrations/aws/defense_evasion_cloudtrail_logging_suspended.toml index 311fe6589..59bfe53ea 100644 --- a/rules/integrations/aws/defense_evasion_cloudtrail_logging_suspended.toml +++ b/rules/integrations/aws/defense_evasion_cloudtrail_logging_suspended.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2020/06/10" maturity = "production" -updated_date = "2021/07/20" +updated_date = "2022/07/22" integration = "aws" [rule] @@ -24,7 +24,64 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS CloudTrail Log Suspended" -note = """## Setup +note = """## Triage and analysis + +### Investigating AWS CloudTrail Log Suspended + +Amazon CloudTrail is a service that enables governance, compliance, operational auditing, and risk auditing of your +Amazon Web Services account. With CloudTrail, you can log, continuously monitor, and retain account activity related to +actions across your Amazon Web Services infrastructure. CloudTrail provides event history of your Amazon Web Services +account activity, including actions taken through the Amazon Management Console, Amazon SDKs, command line tools, and +other Amazon Web Services services. This event history simplifies security analysis, resource change tracking, and +troubleshooting. + +This rule identifies the suspension of an AWS log trail using the API `StopLogging` action. Attackers can do this to +cover their tracks and impact security monitoring that relies on this source. + +#### 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. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the user? + - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source + IP from an EC2 instance that's not under your control? + - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? + Are there any other alerts or signs of suspicious activity involving this instance? +- Investigate the deleted log trail's criticality and whether the responsible team is aware of the deletion. +- 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 IP address 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. +- 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. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify 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/defense_evasion_cloudwatch_alarm_deletion.toml b/rules/integrations/aws/defense_evasion_cloudwatch_alarm_deletion.toml index 9f92d8d1a..e9bc81ed4 100644 --- a/rules/integrations/aws/defense_evasion_cloudwatch_alarm_deletion.toml +++ b/rules/integrations/aws/defense_evasion_cloudwatch_alarm_deletion.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2020/06/15" maturity = "production" -updated_date = "2021/07/20" +updated_date = "2022/07/22" integration = "aws" [rule] @@ -20,7 +20,64 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS CloudWatch Alarm Deletion" -note = """## Setup +note = """## Triage and analysis + +### Investigating AWS CloudWatch Alarm Deletion + +Amazon CloudWatch is a monitoring and observability service that collects monitoring and operational data in the form of +logs, metrics, and events for resources and applications. This data can be used to detect anomalous behavior in your environments, set alarms, visualize +logs and metrics side by side, take automated actions, troubleshoot issues, and discover insights to keep your +applications running smoothly. + +CloudWatch Alarms is a feature that allows you to watch CloudWatch metrics and to receive notifications when the metrics +fall outside of the levels (high or low thresholds) that you configure. + +This rule looks for the deletion of a alarm using the API `DeleteAlarms` action. Attackers can do this to cover their +tracks and evade security defenses. + +#### 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 there is a justification for this behavior. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the user? + - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source + IP from an EC2 instance that's not under your control? + - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? + Are there any other alerts or signs of suspicious activity involving this instance? +- 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 IP address 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. +- 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. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify 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/defense_evasion_ec2_flow_log_deletion.toml b/rules/integrations/aws/defense_evasion_ec2_flow_log_deletion.toml index 1e666509d..56aa312c1 100644 --- a/rules/integrations/aws/defense_evasion_ec2_flow_log_deletion.toml +++ b/rules/integrations/aws/defense_evasion_ec2_flow_log_deletion.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2020/06/15" maturity = "production" -updated_date = "2021/07/20" +updated_date = "2022/07/22" integration = "aws" [rule] @@ -22,8 +22,62 @@ index = ["filebeat-*", "logs-aws*"] interval = "10m" language = "kuery" license = "Elastic License v2" -name = "AWS EC2 Flow Log Deletion" -note = """## Setup +name = "AWS VPC Flow Logs Deletion" +note = """## Triage and analysis + +### Investigating AWS VPC Flow Logs Deletion + +VPC Flow Logs is an AWS feature that enables you to capture information about the IP traffic going to and from network +interfaces in your virtual private cloud (VPC). Flow log data can be published to Amazon CloudWatch Logs or Amazon S3. + +This rule identifies the deletion of VPC flow logs using the API `DeleteFlowLogs` action. Attackers can do this to cover +their tracks and impact security monitoring that relies on this source. + +#### 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. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the user? + - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source + IP from an EC2 instance that's not under your control? + - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? + Are there any other alerts or signs of suspicious activity involving this instance? +- 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 IP address conditions. +- Administrators may rotate these logs after a certain period as part of their retention policy or after importing them +to a SIEM. + +### 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. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify 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/impact_cloudtrail_logging_updated.toml b/rules/integrations/aws/impact_cloudtrail_logging_updated.toml index d0465dcf1..8784d4261 100644 --- a/rules/integrations/aws/impact_cloudtrail_logging_updated.toml +++ b/rules/integrations/aws/impact_cloudtrail_logging_updated.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2020/06/10" maturity = "production" -updated_date = "2021/07/20" +updated_date = "2022/07/22" integration = "aws" [rule] @@ -20,7 +20,64 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS CloudTrail Log Updated" -note = """## Setup +note = """## Triage and analysis + +### Investigating AWS CloudTrail Log Updated + +Amazon CloudTrail is a service that enables governance, compliance, operational auditing, and risk auditing of your +Amazon Web Services account. With CloudTrail, you can log, continuously monitor, and retain account activity related to +actions across your Amazon Web Services infrastructure. CloudTrail provides event history of your Amazon Web Services +account activity, including actions taken through the Amazon Management Console, Amazon SDKs, command line tools, and +other Amazon Web Services services. This event history simplifies security analysis, resource change tracking, and +troubleshooting. + +This rule identifies a modification on CloudTrail settings using the API `UpdateTrail` action. Attackers can do this to +cover their tracks and impact security monitoring that relies on this source. + +#### Possible investigation steps + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Examine the response elements of the event to determine the scope of the changes. +- 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. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the user? + - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source + IP from an EC2 instance that's not under your control? + - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? + Are there any other alerts or signs of suspicious activity involving this instance? +- 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 IP address 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. +- 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. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify 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/impact_cloudwatch_log_group_deletion.toml b/rules/integrations/aws/impact_cloudwatch_log_group_deletion.toml index db3f0d910..2af9ef080 100644 --- a/rules/integrations/aws/impact_cloudwatch_log_group_deletion.toml +++ b/rules/integrations/aws/impact_cloudwatch_log_group_deletion.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2020/05/18" maturity = "production" -updated_date = "2021/07/20" +updated_date = "2022/07/22" integration = "aws" [rule] @@ -23,7 +23,66 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS CloudWatch Log Group Deletion" -note = """## Setup +note = """## Triage and analysis + +### Investigating AWS CloudWatch Log Group Deletion + +Amazon CloudWatch is a monitoring and observability service that collects monitoring and operational data in the form of +logs, metrics, and events for resources and applications. This data can be used to detect anomalous behavior in your environments, set alarms, visualize +logs and metrics side by side, take automated actions, troubleshoot issues, and discover insights to keep your +applications running smoothly. + +A log group is a group of log streams that share the same retention, monitoring, and access control settings. You can +define log groups and specify which streams to put into each group. There is no limit on the number of log streams that +can belong to one log group. + +This rule looks for the deletion of a log group using the API `DeleteLogGroup` action. Attackers can do this to cover +their tracks and impact security monitoring that relies on these sources. + +#### 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. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the user? + - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source + IP from an EC2 instance that's not under your control? + - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? + Are there any other alerts or signs of suspicious activity involving this instance? +- Investigate the deleted log group's criticality and whether the responsible team is aware of the deletion. +- 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 IP address 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. +- 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. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify 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_console_login_root.toml b/rules/integrations/aws/initial_access_console_login_root.toml index 24f578269..1c2690d6c 100644 --- a/rules/integrations/aws/initial_access_console_login_root.toml +++ b/rules/integrations/aws/initial_access_console_login_root.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2020/06/11" maturity = "production" -updated_date = "2021/07/20" +updated_date = "2022/07/22" integration = "aws" [rule] @@ -21,13 +21,55 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS Management Console Root Login" -note = """## Setup +note = """## Triage and analysis + +### Investigating AWS Management Console Root Login + +The AWS root account is the one identity that has complete access to all AWS services and resources in the account, +which is created when the AWS account is created. AWS strongly recommends that you do not use the root user for your +everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create +your first IAM user. Then securely lock away the root user credentials and use them to perform only a few account and +service management tasks. AWS provides a [list of the tasks that require root user](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root). + +This rule looks for attempts to log in to the AWS Management Console as the root user. + +#### Possible investigation steps + +- Investigate other alerts associated with the user account during the past 48 hours. +- Examine whether this activity is common in the environment by looking for past occurrences on your logs. +- Consider the source IP address and geolocation for the calling user who issued the command. Do they look normal for the + calling user? +- Examine the commands, API calls, and data management actions performed by the account in the last 24 hours. +- Contact the account owner and confirm whether they are aware of this activity. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking access to servers, +services, and data accessed by the account in the last 24 hours. + +### False positive analysis + +- The alert can be dismissed if this operation is done under change management and approved according to the +organization's policy for performing a task that needs this privilege level. + +### 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. + - Identify the services or servers involved criticality. + - 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 if there are any regulatory or legal ramifications related to this activity. +- Configure multi-factor authentication for the user. +- Follow security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- 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/UserGuide/id_root-user.html"] -risk_score = 73 +risk_score = 47 rule_id = "e2a67480-3b79-403d-96e3-fdd2992c50ef" -severity = "high" +severity = "medium" tags = ["Elastic", "Cloud", "AWS", "Continuous Monitoring", "SecOps", "Identity and Access"] timestamp_override = "event.ingested" type = "query" diff --git a/rules/integrations/aws/privilege_escalation_root_login_without_mfa.toml b/rules/integrations/aws/privilege_escalation_root_login_without_mfa.toml index 21d0c74fb..1d1be7716 100644 --- a/rules/integrations/aws/privilege_escalation_root_login_without_mfa.toml +++ b/rules/integrations/aws/privilege_escalation_root_login_without_mfa.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2020/07/06" maturity = "production" -updated_date = "2021/07/20" +updated_date = "2022/07/22" integration = "aws" [rule] @@ -22,7 +22,57 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS Root Login Without MFA" -note = """## Setup +note = """## Triage and analysis + +### Investigating AWS Root Login Without MFA + +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, as well as for an authentication code from their AWS MFA device. 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). + +The AWS root account is the one identity that has complete access to all AWS services and resources in the account, +which is created when the AWS account is created. AWS strongly recommends that you do not use the root user for your +everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create +your first IAM user. Then securely lock away the root user credentials and use them to perform only a few account and +service management tasks. Amazon provides a [list of the tasks that require root user](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root). + +This rule looks for attempts to log in to AWS as the root user without using multi-factor authentication (MFA), meaning +the account is not secured properly. + +#### Possible investigation steps + +- Investigate other alerts associated with the user account during the past 48 hours. +- Examine whether this activity is common in the environment by looking for past occurrences on your logs. +- Consider the source IP address and geolocation for the calling user who issued the command. Do they look normal for the + calling user? +- Examine the commands, API calls, and data management actions performed by the account in the last 24 hours. +- Contact the account owner and confirm whether they are aware of this activity. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking access to servers, +services, and data accessed by the account in the last 24 hours. + +### False positive analysis + +- While this activity is not inherently malicious, the root account must use MFA. The security team should address any +potential benign true positive (B-TP), as this configuration can risk the entire cloud environment. + +### 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. + - Identify the services or servers involved criticality. + - 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 if there are any regulatory or legal ramifications related to this activity. +- Configure multi-factor authentication for the user. +- Follow security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- 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/UserGuide/id_root-user.html"] diff --git a/rules/integrations/azure/persistence_mfa_disabled_for_azure_user.toml b/rules/integrations/azure/persistence_mfa_disabled_for_azure_user.toml index 84b1fa3ef..aab929854 100644 --- a/rules/integrations/azure/persistence_mfa_disabled_for_azure_user.toml +++ b/rules/integrations/azure/persistence_mfa_disabled_for_azure_user.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2020/08/20" maturity = "production" -updated_date = "2021/07/20" +updated_date = "2022/07/22" integration = "azure" [rule] @@ -15,7 +15,57 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Multi-Factor Authentication Disabled for an Azure User" -note = """## Setup +note = """## Triage and analysis + +### Investigating Multi-Factor Authentication Disabled for an Azure User + +Multi-factor authentication is a process in which users are prompted during the sign-in process for an additional form +of identification, such as a code on their cellphone or a fingerprint scan. + +If you only use a password to authenticate a user, it leaves an insecure vector for attack. If the password is weak or +has been exposed elsewhere, an attacker could be using it to gain access. When you require a second form of authentication, +security is increased because this additional factor isn't something that's easy for an attacker to obtain or duplicate. + +For more information about using MFA in Azure AD, access the [official documentation](https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-mfa-howitworks#how-to-enable-and-use-azure-ad-multi-factor-authentication). + +This rule identifies the deactivation of MFA for an Azure user account. This modification weakens 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 defaults [provided by Microsoft](https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/concept-fundamentals-security-defaults). +- 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.""" risk_score = 47 diff --git a/rules/integrations/google_workspace/impact_google_workspace_mfa_enforcement_disabled.toml b/rules/integrations/google_workspace/impact_google_workspace_mfa_enforcement_disabled.toml index 5f445561b..c0b08b820 100644 --- a/rules/integrations/google_workspace/impact_google_workspace_mfa_enforcement_disabled.toml +++ b/rules/integrations/google_workspace/impact_google_workspace_mfa_enforcement_disabled.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2020/11/17" maturity = "production" -updated_date = "2022/07/17" +updated_date = "2022/07/22" integration = "google_workspace" min_stack_comments = "Google Workspace schema deprecated gsuite fields in 8.0" min_stack_version = "8.0" @@ -24,7 +24,57 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "Google Workspace MFA Enforcement Disabled" -note = """## Setup +note = """## Triage and analysis + +### Investigating Google Workspace MFA Enforcement Disabled + +Multi-factor authentication is a process in which users are prompted during the sign-in process for an additional form +of identification, such as a code on their cellphone or a fingerprint scan. + +If you only use a password to authenticate a user, it leaves an insecure vector for attack. If the password is weak or +has been exposed elsewhere, an attacker could be using it to gain access. When you require a second form of authentication, +security is increased because this additional factor isn't something that's easy for an attacker to obtain or duplicate. + +For more information about using MFA in Google Workspace, access the [official documentation](https://support.google.com/a/answer/175197). + +This rule identifies the disabling of MFA enforcement in Google Workspace. This modification weakens the security of +the accounts 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 the multi-factor authentication enforcement. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google. +- 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 Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.