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

nldcsc_elastic_rules/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml

@@ -0,0 +1,107 @@
+[metadata]
+creation_date = "2021/07/19"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/11/18"
+
+[rule]
+author = ["Austin Songer"]
+description = """
+Identifies when an ElastiCache security group has been created. Amazon EC2-Classic and ElastiCache CacheSecurityGroups
+have been retired. Modern ElastiCache deployments run in a VPC and use standard EC2 security groups instead. This rule
+should be retained only for historical log analysis on legacy CloudTrail data. We recommend relying on "AWS EC2 Security
+Group Configuration Change" rule for network-control changes impacting ElastiCache in VPC-based deployments.
+"""
+false_positives = [
+    """
+    A ElastiCache security group may be created by a system or network administrator. Verify whether the user identity,
+    user agent, and/or hostname should be making changes in your environment. Security group creations 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 = "Deprecated - AWS ElastiCache Security Group Created"
+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 Deprecated - AWS ElastiCache Security Group Created
+
+AWS ElastiCache security groups control access to cache clusters, ensuring only authorized traffic can interact with them. Adversaries might create new security groups to bypass existing restrictions, facilitating unauthorized access or data exfiltration. The detection rule monitors for successful creation events of these groups, signaling potential defense evasion tactics by identifying unusual or unauthorized configurations.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs for the specific event.action "Create Cache Security Group" to identify the user or role that initiated the creation of the ElastiCache security group.
+- Examine the event.provider field to confirm that the event is associated with elasticache.amazonaws.com, ensuring the alert is relevant to ElastiCache services.
+- Check the event.outcome field to verify that the security group creation was successful, confirming the alert's validity.
+- Investigate the IAM permissions and roles associated with the user or entity that created the security group to determine if they have legitimate access and reasons for this action.
+- Analyze the configuration of the newly created ElastiCache security group to identify any overly permissive rules or unusual configurations that could indicate malicious intent.
+- Correlate this event with other recent activities in the AWS account, such as changes to IAM policies or unusual login attempts, to assess if this is part of a broader attack pattern.
+
+### False positive analysis
+
+- Routine administrative actions by authorized personnel can trigger this rule. Regularly review and document legitimate security group creation activities to differentiate them from suspicious actions.
+- Automated processes or scripts that create security groups as part of normal operations may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts.
+- Infrastructure as Code (IaC) tools like Terraform or CloudFormation might create security groups during deployments. Ensure these tools and their actions are well-documented and consider excluding their known patterns from triggering alerts.
+- Development and testing environments often involve frequent creation and deletion of resources, including security groups. Establish separate monitoring rules or exceptions for these environments to reduce noise.
+- Scheduled maintenance or updates that involve security group modifications should be communicated to the security team in advance, allowing them to temporarily adjust monitoring rules or expectations.
+
+### Response and remediation
+
+- Immediately review the newly created ElastiCache security group to verify its necessity and ensure it aligns with organizational security policies. If unauthorized, proceed to delete the security group to prevent potential misuse.
+- Conduct a thorough audit of recent IAM activity to identify any unauthorized access or privilege escalation that may have led to the creation of the security group. Pay special attention to any anomalies in user behavior or access patterns.
+- Isolate any affected ElastiCache instances by temporarily restricting access to them until a full assessment is completed. This helps prevent any potential data exfiltration or unauthorized access.
+- Notify the security operations team and relevant stakeholders about the incident for further investigation and to ensure awareness across the organization.
+- Implement additional monitoring on the AWS account to detect any further unauthorized changes to security groups or other critical configurations, enhancing the detection capabilities for similar threats.
+- Review and update IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of unauthorized security group creation in the future.
+- If the incident is confirmed as malicious, escalate to the incident response team for a comprehensive investigation and to determine if further actions, such as legal or regulatory reporting, are necessary.
+
+## 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/AmazonElastiCache/latest/APIReference/API_CreateCacheSecurityGroup.html",
+]
+risk_score = 21
+rule_id = "7b3da11a-60a2-412e-8aa7-011e1eb9ed47"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:aws.cloudtrail and event.provider:elasticache.amazonaws.com and event.action:"Create Cache Security Group" 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.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_elasticache_security_group_modified_or_deleted.toml

@@ -0,0 +1,107 @@
+[metadata]
+creation_date = "2021/07/19"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/11/18"
+
+[rule]
+author = ["Austin Songer"]
+description = """
+Identifies when an ElastiCache security group has been modified or deleted. Amazon EC2-Classic and ElastiCache
+CacheSecurityGroups have been retired. Modern ElastiCache deployments run in a VPC and use standard EC2 security groups
+instead. This rule should be retained only for historical log analysis on legacy CloudTrail data. We recommend relying
+on "AWS EC2 Security Group Configuration Change" rule for network-control changes impacting ElastiCache in VPC-based
+deployments.
+"""
+false_positives = [
+    """
+    A ElastiCache security group deletion may be done by a system or network administrator. Verify whether the user
+    identity, user agent, and/or hostname should be making changes in your environment. Security Group 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 = "Deprecated - AWS ElastiCache Security Group Modified or Deleted"
+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 Deprecated - AWS ElastiCache Security Group Modified or Deleted
+
+AWS ElastiCache security groups control inbound and outbound traffic to cache clusters, ensuring only authorized access. Adversaries may modify or delete these groups to bypass security controls, facilitating unauthorized data access or exfiltration. The detection rule monitors specific API actions related to security group changes, flagging successful modifications or deletions as potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs for the specific event.provider: elasticache.amazonaws.com to identify the user or role that initiated the security group modification or deletion.
+- Examine the event.action field to determine the exact action taken, such as "Delete Cache Security Group" or "Authorize Cache Security Group Ingress", and assess the potential impact on security posture.
+- Check the event.outcome field to confirm the success of the action and correlate it with any other suspicious activities in the same timeframe.
+- Investigate the source IP address and location associated with the event to determine if it aligns with expected administrative activity.
+- Review the AWS IAM policies and permissions associated with the user or role to ensure they are appropriate and have not been overly permissive.
+- Assess the affected ElastiCache clusters to determine if any unauthorized access or data exfiltration attempts have occurred following the security group change.
+
+### False positive analysis
+
+- Routine maintenance activities by authorized personnel can trigger alerts when they modify security groups for legitimate reasons. To manage this, create exceptions for known maintenance windows or specific user actions.
+- Automated scripts or tools used for infrastructure management might modify security groups as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific user or role identifiers.
+- Changes made by cloud management platforms or third-party services that integrate with AWS may also result in false positives. Review and whitelist these services if they are verified as non-threatening.
+- Regular updates or deployments that require temporary security group modifications can be mistaken for suspicious activity. Document these processes and adjust the detection rule to account for these expected changes.
+- Ensure that any changes made by trusted IP addresses or within a specific network range are reviewed and potentially excluded from alerting, as they may represent internal, authorized activities.
+
+### Response and remediation
+
+- Immediately isolate the affected ElastiCache instance by applying restrictive security group rules to prevent further unauthorized access.
+- Review CloudTrail logs to identify any unauthorized API calls related to the security group modifications and determine the source of the changes.
+- Revert any unauthorized changes to the ElastiCache security groups by restoring them to their previous state using backups or documented configurations.
+- Conduct a thorough investigation to identify any data exfiltration or unauthorized access that may have occurred due to the security group changes.
+- Escalate the incident to the security operations team for further analysis and to determine if additional security measures are required.
+- Implement additional monitoring and alerting for changes to ElastiCache security groups to ensure rapid detection of similar threats in the future.
+- Review and update IAM policies to ensure that only authorized personnel have permissions to modify ElastiCache security groups, reducing the risk of future unauthorized changes.
+
+## 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/AmazonElastiCache/latest/APIReference/Welcome.html"]
+risk_score = 21
+rule_id = "1ba5160d-f5a2-4624-b0ff-6a1dc55d2516"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:aws.cloudtrail and event.provider:elasticache.amazonaws.com and event.action:("Delete Cache Security Group" or
+"Authorize Cache Security Group Ingress" or  "Revoke Cache Security Group Ingress" or "AuthorizeCacheSecurityGroupEgress" or
+"RevokeCacheSecurityGroupEgress") 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.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_guardduty_detector_deletion.toml

@@ -0,0 +1,153 @@
+[metadata]
+creation_date = "2020/05/28"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/11/12"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects the deletion of an Amazon GuardDuty detector. GuardDuty provides continuous monitoring for malicious or
+unauthorized activity across AWS accounts. Deleting the detector disables this visibility, stopping all threat detection
+and removing existing findings. Adversaries may delete GuardDuty detectors to impair security monitoring and evade
+detection during or after an intrusion. This rule identifies successful "DeleteDetector" API calls and can indicate a
+deliberate defense evasion attempt.
+"""
+false_positives = [
+    """
+    The GuardDuty detector 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. Detector 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-6m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "AWS GuardDuty Detector 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 GuardDuty Detector Deletion
+
+Amazon GuardDuty is a continuous threat detection service that analyzes CloudTrail, DNS, and VPC Flow Logs to identify malicious activity and compromised resources. Deleting a GuardDuty detector stops this monitoring entirely and permanently removes all historical findings for the affected AWS account. This rule detects successful `DeleteDetector` API calls, which may represent an attacker attempting to impair defenses and evade detection. Such actions should be rare and always performed under controlled administrative change processes.
+
+#### Possible investigation steps
+
+- **Identify the actor**
+  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to determine who initiated the deletion.
+  - Verify whether this principal normally performs GuardDuty configuration or administrative tasks.
+
+- **Review request context**
+  - Check `aws.cloudtrail.request_parameters` and `cloud.region` to confirm the targeted GuardDuty detector and scope of impact.
+  - Determine whether multiple detectors or member accounts were affected (especially in delegated admin organizations).
+
+- **Analyze source and access patterns**
+  - Review `source.ip`, `user_agent.original` and `source.geo` fields for anomalous or previously unseen access locations or automation clients.
+  - Check whether the deletion occurred outside standard maintenance windows or during a concurrent suspicious activity window.
+
+- **Correlate with preceding or related activity**
+  - Search for earlier GuardDuty configuration changes:
+    - `StopMonitoringMembers`, `DisassociateMembers`, or `DeleteMembers`
+    - IAM role or policy modifications reducing GuardDuty privileges
+  - Look for other defense evasion indicators such as CloudTrail suspension, Security Hub configuration changes, or disabling of AWS Config rules.
+
+- **Review historical GuardDuty findings**
+  - Examine prior GuardDuty alerts and findings (if still retrievable) to determine whether the deletion followed significant detection activity.
+  - Use centralized logs or security data lakes to recover findings removed from the console.
+
+### False positive analysis
+
+- **Authorized administrative actions**
+  - Verify whether the deletion corresponds to legitimate account decommissioning, region cleanup, or migration activity.
+- **Automation or IaC**
+  - GuardDuty may be disabled temporarily during infrastructure provisioning or teardown in automated environments. 
+    Confirm via CI/CD logs or Infrastructure-as-Code templates.
+- **Organizational configuration changes**
+  - Large organizations might consolidate GuardDuty under a delegated administrator account, causing detectors to be deleted in member accounts. 
+    Validate these actions against security architecture changes.
+
+### Response and remediation
+
+- **Containment and restoration**
+  - If unauthorized, immediately re-enable GuardDuty in the affected account and region using the `CreateDetector` API or AWS console.
+  - Verify that findings aggregation and member account associations are restored to expected configurations.
+
+- **Investigation**
+  - Review CloudTrail for related privilege escalation or resource tampering events around the deletion time.
+  - Assess whether any attacker activity occurred during the monitoring gap between deletion and restoration.
+
+- **Recovery and hardening**
+  - Restrict `guardduty:DeleteDetector` permissions to a limited administrative role.
+  - Implement AWS Config rules or Security Hub controls to alert on changes to GuardDuty detectors or configuration states.
+  - Enforce least privilege IAM policies, ensuring operational automation cannot disable GuardDuty outside maintenance workflows.
+  - Document approved GuardDuty maintenance activities and correlate them with change tickets for traceability.
+
+### Additional information
+- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
+- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
+- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
+"""
+references = [
+    "https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteDetector.html",
+]
+risk_score = 73
+rule_id = "523116c0-d89d-4d7c-82c2-39e6845a78ef"
+severity = "high"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS GuardDuty",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset: aws.cloudtrail 
+  and event.provider: guardduty.amazonaws.com 
+  and event.action: DeleteDetector 
+  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/"
+
+[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",
+    "target.entity.id",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+]
+

nldcsc_elastic_rules/rules/integrations/aws/defense_evasion_rds_instance_restored.toml

@@ -0,0 +1,106 @@
+[metadata]
+creation_date = "2021/06/29"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Austin Songer", "Elastic"]
+description = """
+An adversary with a set of compromised credentials may attempt to make copies of running or deleted RDS databases in order to evade defense mechanisms or access data. This rule identifies successful attempts to restore a DB instance using the RDS `RestoreDBInstanceFromDBSnapshot` or `RestoreDBInstanceFromS3` API operations.
+"""
+false_positives = [
+    """
+    Restoring DB instances may be done by a system or network administrator. Verify whether the user identity, user agent,
+    and/or hostname should be making changes in your environment. Instance restoration by unfamiliar users or hosts
+    should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    """,
+]
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "AWS RDS DB Instance Restored"
+references = [
+    "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html",
+    "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html",
+    "https://github.com/RhinoSecurityLabs/pacu/blob/master/pacu/modules/rds__explore_snapshots/main.py",
+    "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation#rds-createdbsnapshot-rds-restoredbinstancefromdbsnapshot-rds-modifydbinstance",
+]
+risk_score = 47
+rule_id = "bf1073bf-ce26-4607-b405-ba1ed8e9e204"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS RDS",
+    "Use Case: Asset Visibility",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+any where event.dataset == "aws.cloudtrail"
+    and event.provider == "rds.amazonaws.com"
+    and event.action in ("RestoreDBInstanceFromDBSnapshot", "RestoreDBInstanceFromS3")
+    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 RDS DB Instance Restored
+
+Amazon RDS (Relational Database Service) allows users to set up, operate, and scale databases in the cloud. Adversaries may exploit RDS by restoring DB instances from snapshots or S3 to access sensitive data or bypass security controls. The detection rule identifies successful restoration attempts, signaling potential unauthorized access or data exfiltration activities, by monitoring specific API operations and outcomes.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs to identify the user or role associated with the successful `RestoreDBInstanceFromDBSnapshot` or `RestoreDBInstanceFromS3` API call by examining the `user.identity` field.
+- Check the source IP address and location from which the API call was made using the `sourceIPAddress` field to determine if it aligns with expected or known locations.
+- Investigate the timing of the restoration event by looking at the `@timestamp` field to see if it coincides with any other suspicious activities or anomalies in the environment.
+- Examine the specific DB instance details restored, such as the DB instance identifier, to assess the sensitivity of the data involved and potential impact.
+- Verify if there are any associated alerts or logs indicating unauthorized access or data exfiltration attempts around the same time frame.
+- Contact the user or team responsible for the credentials used, if legitimate, to confirm whether the restoration was authorized and intended.
+
+### False positive analysis
+
+- Routine database maintenance or testing activities may trigger the rule. Organizations should identify and document regular restoration activities performed by authorized personnel and exclude these from alerts.
+- Automated backup and restore processes used for disaster recovery or data migration can result in false positives. Users should configure exceptions for known automated processes by filtering based on specific user accounts or roles.
+- Development and staging environments often involve frequent restoration of databases for testing purposes. Exclude these environments by identifying and filtering out specific instance identifiers or tags associated with non-production environments.
+- Scheduled tasks or scripts that restore databases as part of regular operations can be mistaken for unauthorized activity. Ensure these tasks are well-documented and create exceptions based on the source IP or IAM role used for these operations.
+- Third-party services or integrations that require database restoration for functionality may trigger alerts. Verify these services and exclude their associated actions by identifying their unique user agents or API keys.
+
+### Response and remediation
+
+- Immediately isolate the restored RDS instance to prevent unauthorized access. This can be done by modifying the security group rules to restrict inbound and outbound traffic.
+- Conduct a thorough review of CloudTrail logs to identify the source of the compromised credentials and any other suspicious activities associated with the same user or account.
+- Revoke the compromised credentials and issue new credentials for the affected user or service account. Ensure that multi-factor authentication (MFA) is enabled for all accounts.
+- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized restoration and any potential data exposure.
+- Perform a security assessment of the restored RDS instance to identify any unauthorized changes or data exfiltration. This includes checking for unusual queries or data exports.
+- Implement additional monitoring and alerting for similar API operations to detect future unauthorized restoration attempts promptly.
+- Review and update IAM policies to ensure that only authorized users have the necessary permissions to restore RDS instances, reducing the risk of future incidents."""
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1578"
+name = "Modify Cloud Compute Infrastructure"
+reference = "https://attack.mitre.org/techniques/T1578/"
+[[rule.threat.technique.subtechnique]]
+id = "T1578.002"
+name = "Create Cloud Instance"
+reference = "https://attack.mitre.org/techniques/T1578/002/"
+[[rule.threat.technique.subtechnique]]
+id = "T1578.004"
+name = "Revert Cloud Instance"
+reference = "https://attack.mitre.org/techniques/T1578/004/"
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml

@@ -0,0 +1,100 @@
+[metadata]
+creation_date = "2024/04/12"
+integration = ["aws"]
+maturity = "production"
+updated_date = "2025/01/10"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when a Route53 Resolver Query Log Configuration is deleted. When a Route53 Resolver query log configuration
+is deleted, Resolver stops logging DNS queries and responses for the specified configuration. Adversaries may delete
+query log configurations to evade detection or cover their tracks.
+"""
+false_positives = ["Legitimate deletion of Route53 Resolver Query Log Configuration by authorized personnel."]
+from = "now-60m"
+index = ["filebeat-*", "logs-aws.cloudtrail*"]
+interval = "10m"
+language = "kuery"
+license = "Elastic License v2"
+name = "Route53 Resolver Query Log Configuration Deleted"
+note = """
+## Triage and analysis
+
+### Investigating Route53 Resolver Query Log Configuration Deleted
+
+This rule detects when a Route53 Resolver Query Log Configuration is deleted. Deleting these configurations stops the logging of DNS queries and responses, which can significantly impede network monitoring and compromise security visibility. Adversaries may delete these configurations to evade detection, remove evidence, or obscure their activities within a network.
+
+Adversaries target Route53 Resolver query log configurations because these logs can contain evidence of malicious domain queries or responses. By deleting these logs, an adversary can prevent the capture of information that could reveal unauthorized network activities, aiding in avoiding detection and thwarting incident response efforts.
+
+#### Possible Investigation Steps
+
+- **Review the Deletion Details**: Examine the CloudTrail logs to identify when and by whom the deletion was initiated.
+    - Check the `event.action` and `user_identity` elements to understand the scope and authorization of the deletion.
+- **Contextualize with User Actions**: Assess whether the deletion aligns with the user’s role and job responsibilities.
+    - Investigate if similar modifications have occurred recently that could suggest a pattern or broader campaign.
+- **Analyze Access Patterns and Permissions**: Verify whether the user had the appropriate permissions to delete log configurations.
+    - Investigate any recent permission changes that might indicate role abuse or credentials compromise.
+- **Correlate with Other Security Incidents**: Look for related security alerts or incidents that could be connected to the log deletion.
+    - This includes unusual network traffic, alerts from other AWS services, or findings from intrusion detection systems.
+- **Interview the Responsible Team**: If the deletion was initiated by an internal team member, confirm their intent and authorization to ensure it was a legitimate action.
+
+### False Positive Analysis
+
+- **Legitimate Administrative Actions**: Confirm that the deletion was part of scheduled IT operations or network management activities, possibly linked to maintenance or infrastructure updates. Validate this action against change management records or through interviews with relevant personnel.
+
+### Response and Remediation
+
+- **Restore Logs if Feasible**: If the deletion was unauthorized, consider restoring the configuration from backups to ensure continuous visibility into DNS queries.
+- **Review and Tighten Permissions**: Ensure that only authorized personnel have the capability to delete critical configurations.
+    - Adjust AWS IAM policies to reinforce security measures.
+- **Enhance Monitoring of Log Management**: Implement or enhance monitoring rules to detect and alert on unauthorized changes to logging configurations, focusing on critical deletions.
+- **Conduct Comprehensive Security Review**: If the deletion is verified as malicious, initiate a thorough security assessment to identify any further unauthorized changes or ongoing malicious activities.
+
+### Additional Information
+
+For detailed instructions on managing Route53 Resolver and securing its configurations, refer to the [Amazon Route53 Resolver documentation](https://docs.aws.amazon.com/Route53/latest/APIReference/API_route53resolver_DeleteResolverQueryLogConfig.html).
+
+"""
+references = [
+    "https://docs.aws.amazon.com/Route53/latest/APIReference/API_route53resolver_DeleteResolverQueryLogConfig.html",
+]
+risk_score = 47
+rule_id = "453183fa-f903-11ee-8e88-f661ea17fbce"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: Amazon Route53",
+    "Use Case: Log Auditing",
+    "Resources: Investigation Guide",
+    "Tactic: Defense Evasion",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:aws.cloudtrail and event.provider: route53resolver.amazonaws.com
+    and event.action: DeleteResolverQueryLogConfig 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/"
+