[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 <joe.peeples@elastic.co>

* Update rules/integrations/aws/defense_evasion_cloudtrail_logging_suspended.toml

* update dates

* Apply suggestions from review

Co-authored-by: Joe Peeples <joe.peeples@elastic.co>

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 = [

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 = [

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 = [

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 = [

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 = [

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 = [

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"

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"]

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

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.