nldcsc-elastic-rules 0.0.8__py3-none-any.whl

nldcsc_elastic_rules/rules/integrations/aws/defense_evasion_sqs_purge_queue.toml

@@ -0,0 +1,171 @@
+[metadata]
+creation_date = "2025/01/08"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when an AWS Simple Queue Service (SQS) queue is purged. Adversaries may purge SQS queues to disrupt
+operations, delete messages, or impair monitoring and alerting mechanisms. This action can be used to evade detection
+and cover tracks by removing evidence of malicious activities.
+"""
+false_positives = [
+    "Administrators may purge SQS queues for legitimate reasons, such as removing outdated or sensitive data.",
+]
+from = "now-9m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "AWS SQS Queue Purge"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating AWS SQS Queue Purge
+
+AWS Simple Queue Service (SQS) is a managed message queuing service that enables decoupling and scaling of microservices, distributed systems, and serverless applications. Adversaries may exploit SQS by purging queues to erase messages, disrupt operations, or hinder monitoring. The detection rule identifies successful purge actions in AWS CloudTrail logs, signaling potential defense evasion attempts by adversaries.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs for the specific event.provider "sqs.amazonaws.com" and event.action "PurgeQueue" to identify the time and source of the purge action.
+- Identify the IAM user or role associated with the purge action by examining the user identity information in the CloudTrail logs to determine if the action was authorized or potentially malicious.
+- Check the event.outcome "success" to confirm that the purge action was completed successfully and assess the impact on the queue's message data.
+- Investigate the context around the purge event by reviewing preceding and subsequent CloudTrail logs to identify any related or suspicious activities, such as unauthorized access attempts or changes to IAM policies.
+- Assess the potential impact on operations and monitoring by determining which messages were purged and if they contained critical or sensitive information.
+- Evaluate the necessity of implementing additional security measures, such as stricter IAM policies or enhanced logging and alerting, to prevent unauthorized queue purges in the future.
+
+### False positive analysis
+
+- Routine maintenance activities by administrators may trigger the purge action. To handle this, identify and whitelist known maintenance operations or specific IAM roles used by trusted personnel.
+- Automated scripts or applications that regularly purge queues as part of their normal operation can cause false positives. Review and document these processes, then create exceptions for these specific actions in your monitoring system.
+- Testing environments where queues are frequently purged for development purposes can lead to alerts. Exclude these environments from the rule by filtering based on environment tags or specific queue names.
+- Scheduled tasks that include queue purging as a cleanup mechanism might be misinterpreted as malicious. Ensure these tasks are logged and approved, and adjust the detection rule to ignore these scheduled events.
+- Third-party integrations that manage SQS queues and perform purges as part of their functionality should be assessed. Verify the legitimacy of these integrations and exclude their actions from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected AWS SQS queue to prevent further unauthorized purging or access. This can be done by modifying the queue's access policies to restrict permissions temporarily.
+- Review AWS CloudTrail logs to identify the source of the purge action, including the IAM user or role responsible, and assess whether the action was authorized or part of a larger malicious activity.
+- Revoke or adjust permissions for the identified IAM user or role to prevent further unauthorized actions. Ensure that only necessary permissions are granted following the principle of least privilege.
+- Restore any critical messages or data that were purged, if possible, from backups or other data recovery solutions to minimize operational disruption.
+- Notify the security team and relevant stakeholders about the incident, providing details of the purge action and any identified malicious activity, to ensure coordinated response efforts.
+- Conduct a thorough review of IAM policies and access controls related to SQS to identify and remediate any potential security gaps that could be exploited in the future.
+- Enhance monitoring and alerting mechanisms for AWS SQS by implementing additional logging and anomaly detection to quickly identify and respond to similar threats in the future.
+
+## Triage and Analysis
+
+### Investigating AWS SQS Queue Purge
+
+This rule detects when an AWS SQS queue is purged, an action that adversaries may use to disrupt operations, delete messages, or impair monitoring and alerting mechanisms. Purging an SQS queue removes all messages, which could be used as a tactic to evade detection by deleting evidence of malicious activity or to disrupt legitimate workflows.
+
+#### Possible Investigation Steps
+
+- **Identify the Actor and Resource**:
+  - **User Identity and Permissions**: Review the field `aws.cloudtrail.user_identity.arn` to identify the IAM user or role responsible for the purge. Validate their permissions and determine if this action aligns with their typical responsibilities.
+  - **SQS Queue Details**: Examine `aws.cloudtrail.resources.arn` and `aws.cloudtrail.flattened.request_parameters.queueUrl` to identify the specific SQS queue that was purged. Check its purpose, associated workflows, and whether it handles sensitive or critical messages.
+
+- **Evaluate the Context and Purpose of the Purge**:
+  - **Time and Frequency**: Check the timestamp (`@timestamp`) to determine when the purge occurred and whether similar events have occurred recently. Frequent or repeated purges may indicate a larger issue or ongoing malicious activity.
+  - **Legitimacy of the Action**: Consult with the owner or administrator of the affected queue to verify if the purge was intentional or authorized.
+
+- **Analyze for Potential Indicators of Malicious Activity**:
+  - **Source IP and Geographic Location**: Review `source.ip` and `source.geo` to identify the origin of the request. Anomalies, such as unexpected locations, may indicate compromise.
+  - **User Agent and Tooling**: Check `user_agent.original` to confirm the tool used to perform the purge. The use of unexpected or automated tooling may raise suspicion.
+
+- **Cross-Reference Related Activity**:
+  - **Recent IAM Events**: Search for related IAM or security-related events tied to the same actor, such as `CreateAccessKey`, `AssumeRole`, or `UpdateRolePolicy`, which could indicate privilege escalation or preparation for malicious actions.
+  - **Other SQS Activity**: Look for additional activity involving the same SQS queue, such as `SendMessage`, `ReceiveMessage`, or `DeleteQueue`, to identify further signs of unauthorized usage.
+
+### False Positive Analysis
+
+- **Legitimate Administrative Activity**: Administrators may purge SQS queues as part of maintenance or cleanup processes. Validate whether the action was part of an approved operation.
+- **Automation or Testing**: Automation tools or testing processes may perform queue purges as part of their workflow. Verify if the action aligns with known automated tasks or test scenarios.
+
+### Response and Remediation
+
+- **Immediate Actions**:
+  - **Restrict Access**: If the action appears unauthorized, immediately revoke access for the actor responsible for the purge and investigate potential credential compromise.
+  - **Restore Data**: If the purged queue contained critical or sensitive messages, attempt to restore them from backups if available.
+
+- **Preventative Measures**:
+  - **Enhance Monitoring**: Enable additional monitoring for SQS-related activity to detect unusual patterns, such as frequent purges or changes to queue configurations.
+  - **Audit Permissions**: Review and restrict IAM permissions for SQS to ensure only authorized users or roles can perform sensitive actions like `PurgeQueue`.
+
+- **Policy Updates**:
+  - **Apply Least Privilege**: Adjust IAM policies to enforce the principle of least privilege, ensuring that only necessary permissions are granted. Review the policy assigned to the SQS queue as well to prevent unauthorized purges.
+  - **MFA Enforcement**: Require Multi-Factor Authentication (MFA) for all users with access to sensitive AWS resources.
+
+### Additional Information
+
+For further guidance on AWS SQS operations and best practices, refer to:
+- [AWS SQS PurgeQueue API Documentation](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_PurgeQueue.html)
+"""
+references = [
+    "https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_PurgeQueue.html",
+    "https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/",
+]
+risk_score = 47
+rule_id = "bab88bb8-cdd9-11ef-bd9a-f661ea17fbcd"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS SQS",
+    "Use Case: Threat Detection",
+    "Use Case: Log Auditing",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide"
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:"aws.cloudtrail"
+    and event.provider:"sqs.amazonaws.com"
+    and event.action:"PurgeQueue"
+    and event.outcome:"success"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+[[rule.threat.technique.subtechnique]]
+id = "T1562.008"
+name = "Disable or Modify Cloud Logs"
+reference = "https://attack.mitre.org/techniques/T1562/008/"
+
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "user.name",
+    "aws.cloudtrail.user_identity.arn",
+    "aws.cloudtrail.user_identity.type",
+    "user_agent.original",
+    "aws.cloudtrail.flattened.request_parameters.queueUrl",
+    "event.action",
+    "event.outcome",
+    "cloud.region",
+    "event.provider",
+    "aws.cloudtrail.request_id",
+    "aws.cloudtrail.resources.arn",
+    "source.ip",
+    "source.geo.city_name",
+    "source.geo.region_name",
+    "source.geo.country_name"
+]
+

nldcsc_elastic_rules/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml

@@ -0,0 +1,134 @@
+[metadata]
+creation_date = "2024/08/19"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/08/25"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the first occurrence of an AWS Security Token Service (STS) GetFederationToken request made by a user. The GetFederationToken API call allows users to request temporary security credentials to
+access AWS resources. The maximum expiration period for these tokens is 36 hours and they can be used to create a console signin token even for identities that don't already have one. Adversaries may use this API to obtain temporary credentials for persistence and to bypass IAM API call limitations by gaining console access.
+"""
+from = "now-6m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "AWS First Occurrence of STS GetFederationToken Request by User"
+references = [
+    "https://hackingthe.cloud/aws/post_exploitation/survive_access_key_deletion_with_sts_getfederationtoken/",
+    "https://www.crowdstrike.com/en-us/blog/how-adversaries-persist-with-aws-user-federation/",
+    "https://medium.com/@adan.alvarez/how-attackers-persist-in-aws-using-getfederationtoken-a-simple-and-effective-technique-used-in-the-987ec1f0bdfe/"
+]
+risk_score = 47
+rule_id = "7a5cc9a8-5ea3-11ef-beec-f661ea17fbce"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS",
+    "Data Source: AWS STS",
+    "Use Case: Threat Detection",
+    "Tactic: Defense Evasion",
+    "Tactic: Persistence",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.dataset: "aws.cloudtrail"
+    and event.provider:sts.amazonaws.com
+    and event.action:GetFederationToken
+    and event.outcome:success
+'''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating AWS First Occurrence of STS GetFederationToken Request by User
+
+AWS Security Token Service (STS) enables users to request temporary credentials for accessing AWS resources. While beneficial for legitimate use, adversaries may exploit this to gain unauthorized access. These credentials will remain active for the duration specified (maximum 36 hours), even if the initial compromised identity is deleted. They can also be used to request a console signin token which allows the adversary to make sensitive IAM API calls which would otherwise be denied with the federation token alone. The detection rule identifies unusual activity by flagging the first instance of a `GetFederationToken` request by a user helping to uncover potential misuse aimed at evading defenses and gaining persistence.
+
+### Possible investigation steps
+
+- Review the specific user account associated with the `GetFederationToken` request to determine if the activity aligns with their typical behavior and role within the organization.
+- Examine the AWS CloudTrail logs for additional context around the time of the `GetFederationToken` request, looking for any other unusual or suspicious activities by the same user or related accounts.
+- Check the `source.ip` and `source.geo` fields of the request to identify if it originates from an expected or unexpected location.
+- View the `aws.cloudtrail.response_elements` to find the created `federatedUser.arn`. Investigate the resources accessed by this Federated User to assess if there was any suspicious activity.
+- Consult with the requesting user `aws.cloudtrail.user_identity.arn` to verify if the `GetFederationToken` request was legitimate and necessary for their work tasks.
+
+### False positive analysis
+
+- Routine administrative tasks by cloud administrators may trigger the rule if they are using `GetFederationToken` for legitimate purposes. To manage this, create exceptions for known administrative accounts that regularly perform these actions.
+- Automated scripts or applications that use `GetFederationToken` for legitimate operations might be flagged. Identify these scripts and exclude their associated user accounts from the rule to prevent unnecessary alerts.
+- Third-party services integrated with AWS that require temporary credentials might cause false positives. Review and whitelist these services if they are verified and trusted to avoid repeated alerts.
+- New employees or contractors accessing AWS resources for the first time may trigger the rule. Implement a process to verify their access requirements and exclude their accounts if their actions are deemed non-threatening.
+
+### Response and remediation
+
+- If compromise is verified, attach a policy that denies all actions, effectively preventing any further activity, even from temporary credentials. You can use the AWS-managed policy [AWSDenyAll](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html). This ensures that any temporary credentials generated by the compromised user are also blocked, stopping the attacker’s activities.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Conduct a root cause analysis to determine how the `GetFederationToken` request was initiated and identify any potential security gaps or misconfigurations.
+- Implement additional monitoring and alerting for `GetFederationToken` requests to detect and respond to similar activities promptly in the future.
+- Review and update IAM policies and permissions to ensure that only authorized users have the ability to request temporary credentials, reducing the risk of misuse."""
+
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "user.name",
+    "user_agent.original",
+    "source.ip",
+    "aws.cloudtrail.user_identity.arn",
+    "aws.cloudtrail.user_identity.type",
+    "aws.cloudtrail.user_identity.access_key_id",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+    "aws.cloudtrail.response_elements"
+]
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1550"
+name = "Use Alternate Authentication Material"
+reference = "https://attack.mitre.org/techniques/T1550/"
+[[rule.threat.technique.subtechnique]]
+id = "T1550.001"
+name = "Application Access Token"
+reference = "https://attack.mitre.org/techniques/T1550/001/"
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1098"
+name = "Account Manipulation"
+reference = "https://attack.mitre.org/techniques/T1098/"
+[[rule.threat.technique.subtechnique]]
+id = "T1098.001"
+name = "Additional Cloud Credentials"
+reference = "https://attack.mitre.org/techniques/T1098/001/"
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["aws.cloudtrail.user_identity.arn"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-10d"
+
+

nldcsc_elastic_rules/rules/integrations/aws/defense_evasion_vpc_security_group_ingress_rule_added_for_remote_connections.toml

@@ -0,0 +1,118 @@
+[metadata]
+creation_date = "2024/04/16"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/07/10"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when a specified inbound (ingress) rule is added or adjusted for a VPC security group in AWS EC2. This rule detects when a security group rule is added that allows traffic from any IP address or from a specific IP address to common remote access ports, such as 22 (SSH) or 3389 (RDP). Adversaries may add these rules to allow remote access to VPC instances from any location, increasing the attack surface and potentially exposing the instances to unauthorized access.
+"""
+false_positives = [
+    """
+    Administrators may legitimately add security group rules to allow traffic from any IP address or from specific IP addresses to common remote access ports.
+    """,
+]
+from = "now-6m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+interval = "5m"
+language = "kuery"
+license = "Elastic License v2"
+name = "Insecure AWS EC2 VPC Security Group Ingress Rule Added"
+note = """## Triage and analysis
+
+### Investigating Insecure AWS EC2 VPC Security Group Ingress Rule Added
+
+This rule detects the addition of ingress rules to a VPC security group that allow traffic from any IP address (`0.0.0.0/0` or `::/0`) to sensitive ports commonly used for remote access, such as SSH (port 22) and RDP (port 3389). This configuration change can significantly increase the exposure of EC2 instances to potential threats, making it crucial to understand the context and legitimacy of such changes.
+
+#### Possible Investigation Steps:
+
+- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. Investigate whether this actor has the necessary permissions and typically performs these actions.
+- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand exactly what changes were made to the security group. Check for any unusual parameters that could suggest a misconfiguration or malicious intent.
+- **Analyze the Source of the Request**: Look at the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unusual location could indicate compromised credentials.
+- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the change occurred. Modifications outside of typical business hours might warrant additional scrutiny.
+- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor engaged in other potentially suspicious activities.
+
+### False Positive Analysis:
+
+- **Legitimate Administrative Actions**: Verify if the ingress rule change aligns with scheduled updates, maintenance activities, or legitimate administrative tasks documented in change management tickets or systems.
+- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. Consistency with past legitimate actions might indicate a false alarm.
+- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the change was successful and intended as per policy.
+
+### Response and Remediation:
+
+- **Immediate Review and Reversal if Necessary**: If the change was unauthorized, revert the security group rules to their previous state to close any unintended access.
+- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar security group changes, especially those that open access to well-known ports from any IP address.
+- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning security group management.
+- **Audit Security Groups and Policies**: Conduct a comprehensive audit of all security groups and associated policies to ensure they adhere to the principle of least privilege.
+- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.
+
+### Additional Information:
+
+For further guidance on managing security group rules and securing AWS environments, refer to the [Amazon VPC Security Groups documentation](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) and AWS best practices for security.
+
+"""
+references = [
+    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AuthorizeSecurityGroupEgress.html",
+    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AuthorizeSecurityGroupIngress.html",
+    "https://www.linkedin.com/pulse/my-backdoors-your-aws-infrastructure-part-3-network-micha%C5%82-brygidyn/",
+]
+risk_score = 47
+rule_id = "25e7fee6-fc25-11ee-ba0f-f661ea17fbce"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS EC2",
+    "Use Case: Threat Detection",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset: "aws.cloudtrail"
+    and event.provider: ec2.amazonaws.com
+    and event.action: AuthorizeSecurityGroupIngress
+    and event.outcome: success
+    and aws.cloudtrail.flattened.request_parameters.ipPermissions.items.ipRanges.items.cidrIp: ("0.0.0.0/0" or "::/0")
+    and aws.cloudtrail.flattened.request_parameters.ipPermissions.items.fromPort: (
+        21 or 22 or 23 or 445 or 3389 or 5985 or 5986)
+'''
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "user.name",
+    "user_agent.original",
+    "source.ip",
+    "aws.cloudtrail.user_identity.arn",
+    "aws.cloudtrail.user_identity.type",
+    "aws.cloudtrail.user_identity.access_key_id",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters"
+]
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+[[rule.threat.technique.subtechnique]]
+id = "T1562.007"
+name = "Disable or Modify Cloud Firewall"
+reference = "https://attack.mitre.org/techniques/T1562/007/"
+
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml

@@ -0,0 +1,101 @@
+[metadata]
+creation_date = "2020/05/21"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = "Identifies the deletion of a specified AWS Web Application Firewall (WAF) access control list."
+false_positives = [
+    """
+    Firewall ACL's may be deleted by a system or network administrator. Verify whether the user identity, user agent,
+    and/or hostname should be making changes in your environment. Web ACL deletions by unfamiliar users or hosts should
+    be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    """,
+]
+from = "now-60m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+interval = "10m"
+language = "kuery"
+license = "Elastic License v2"
+name = "AWS WAF Access Control List Deletion"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating AWS WAF Access Control List Deletion
+
+AWS Web Application Firewall (WAF) protects web applications by controlling access based on defined rules. Deleting an Access Control List (ACL) can expose applications to threats by removing these protective rules. Adversaries may exploit this to bypass defenses, facilitating unauthorized access or data exfiltration. The detection rule monitors for successful ACL deletions, signaling potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs for the specific event.action:DeleteWebACL to identify the user or role that initiated the deletion. Check the event.userIdentity field for details.
+- Examine the event.time field to determine when the deletion occurred and correlate it with any other suspicious activities or alerts around the same timeframe.
+- Investigate the event.sourceIPAddress to identify the origin of the request and assess if it aligns with known IP addresses or locations associated with your organization.
+- Check the AWS WAF configuration history to understand the context of the deleted ACL, including its rules and the applications it was protecting.
+- Assess the impact of the ACL deletion by reviewing access logs for the affected applications to identify any unusual or unauthorized access attempts following the deletion.
+- Verify if there are any recent changes in IAM policies or permissions that could have allowed unauthorized users to delete the ACL.
+
+### False positive analysis
+
+- Routine maintenance or updates by authorized personnel may trigger ACL deletions. Verify if the deletion aligns with scheduled maintenance activities and consider excluding these events from alerts.
+- Automated scripts or tools used for infrastructure management might delete and recreate ACLs as part of their normal operation. Identify these scripts and whitelist their actions to prevent unnecessary alerts.
+- Changes in security policies or architecture might necessitate the removal of certain ACLs. Ensure that such changes are documented and approved, and exclude these events from monitoring if they are part of a planned update.
+- Test environments often undergo frequent configuration changes, including ACL deletions. Differentiate between production and test environments and adjust monitoring rules to reduce false positives in non-production settings.
+
+### Response and remediation
+
+- Immediately revoke any access keys or credentials associated with the user or role that performed the ACL deletion to prevent further unauthorized actions.
+- Restore the deleted AWS WAF Access Control List from a backup or recreate it using documented configurations to re-establish protective rules.
+- Conduct a thorough review of recent access logs and CloudTrail events to identify any unauthorized access or data exfiltration attempts that may have occurred following the ACL deletion.
+- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement additional monitoring and alerting for any future attempts to delete or modify AWS WAF ACLs, ensuring rapid detection and response.
+- Review and tighten IAM policies to ensure that only authorized personnel have permissions to delete or modify AWS WAF configurations.
+- Consider enabling AWS Config rules to continuously monitor and alert on changes to critical AWS resources, including WAF ACLs, to prevent similar incidents.
+
+## Setup
+
+The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/waf-regional/delete-web-acl.html",
+    "https://docs.aws.amazon.com/waf/latest/APIReference/API_wafRegional_DeleteWebACL.html",
+]
+risk_score = 47
+rule_id = "91d04cd4-47a9-4334-ab14-084abe274d49"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Use Case: Network Security Monitoring",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:aws.cloudtrail and event.action:DeleteWebACL and event.outcome:success
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+[[rule.threat.technique.subtechnique]]
+id = "T1562.001"
+name = "Disable or Modify Tools"
+reference = "https://attack.mitre.org/techniques/T1562/001/"
+
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml

@@ -0,0 +1,102 @@
+[metadata]
+creation_date = "2020/06/09"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = "Identifies the deletion of a specified AWS Web Application Firewall (WAF) rule or rule group."
+false_positives = [
+    """
+    WAF rules or rule groups may be deleted by a system or network administrator. Verify whether the user identity, user
+    agent, and/or hostname should be making changes in your environment. Rule deletions by unfamiliar users or hosts
+    should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    """,
+]
+from = "now-60m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+interval = "10m"
+language = "kuery"
+license = "Elastic License v2"
+name = "AWS WAF Rule or Rule Group Deletion"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating AWS WAF Rule or Rule Group Deletion
+
+AWS Web Application Firewall (WAF) protects web applications by filtering and monitoring HTTP requests. Adversaries may delete WAF rules or groups to disable security measures, facilitating attacks like SQL injection or cross-site scripting. The detection rule monitors AWS CloudTrail logs for successful deletion actions, signaling potential defense evasion attempts by identifying unauthorized or suspicious deletions.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to identify the user or role associated with the deletion action by examining the userIdentity field.
+- Check the event.time field in the CloudTrail logs to determine when the deletion occurred and correlate it with any other suspicious activities around the same time.
+- Investigate the source IP address and user agent from the CloudTrail logs to assess if the request originated from a known or expected location and device.
+- Verify if the deleted WAF rule or rule group was part of a critical security configuration by reviewing the AWS WAF setup and any associated documentation.
+- Contact the user or team responsible for AWS WAF management to confirm if the deletion was authorized and understand the rationale behind it.
+- Examine any recent changes in IAM policies or permissions that might have allowed unauthorized users to perform the deletion action.
+
+### False positive analysis
+
+- Routine maintenance or updates by authorized personnel can trigger rule deletions. Verify if the deletion aligns with scheduled maintenance activities and consider excluding these events from alerts.
+- Automated scripts or tools used for infrastructure management might delete and recreate WAF rules as part of their normal operation. Identify these scripts and whitelist their actions to prevent unnecessary alerts.
+- Changes in security policies or architecture might necessitate the removal of certain WAF rules. Ensure that such changes are documented and approved, and exclude these documented actions from triggering alerts.
+- Temporary rule deletions for testing purposes by security teams can be mistaken for malicious activity. Coordinate with the security team to log these activities and exclude them from detection rules.
+- Ensure that IAM roles or users with permissions to delete WAF rules are reviewed regularly. Exclude actions performed by trusted roles or users after confirming their legitimacy.
+
+### Response and remediation
+
+- Immediately review AWS CloudTrail logs to confirm the unauthorized deletion of WAF rules or rule groups and identify the source of the action, including the IAM user or role involved.
+- Reapply the deleted WAF rules or rule groups to restore the intended security posture and prevent potential attacks such as SQL injection or cross-site scripting.
+- Temporarily restrict or revoke permissions for the identified IAM user or role to prevent further unauthorized actions until a thorough investigation is completed.
+- Conduct a security review of the affected AWS environment to identify any other potential security gaps or unauthorized changes that may have occurred.
+- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement additional monitoring and alerting for AWS WAF configuration changes to detect and respond to similar unauthorized actions promptly in the future.
+- Consider enabling AWS Config rules to continuously monitor and enforce compliance with WAF configurations, ensuring any unauthorized changes are automatically flagged.
+
+## Setup
+
+The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/waf/delete-rule-group.html",
+    "https://docs.aws.amazon.com/waf/latest/APIReference/API_waf_DeleteRuleGroup.html",
+]
+risk_score = 47
+rule_id = "5beaebc1-cc13-4bfc-9949-776f9e0dc318"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Use Case: Network Security Monitoring",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:aws.cloudtrail and event.provider:(waf.amazonaws.com or waf-regional.amazonaws.com or wafv2.amazonaws.com) and event.action:(DeleteRule or DeleteRuleGroup) and event.outcome:success
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+[[rule.threat.technique.subtechnique]]
+id = "T1562.001"
+name = "Disable or Modify Tools"
+reference = "https://attack.mitre.org/techniques/T1562/001/"
+
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+