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

nldcsc_elastic_rules/rules/integrations/aws/credential_access_aws_iam_assume_role_brute_force.toml

@@ -1,105 +0,0 @@
-[metadata]
-creation_date = "2020/07/16"
-integration = ["aws"]
-maturity = "production"
-updated_date = "2024/05/21"
-
-[rule]
-author = ["Elastic"]
-description = """
-Identifies a high number of failed attempts to assume an AWS Identity and Access Management (IAM) role. IAM roles are
-used to delegate access to users or services. An adversary may attempt to enumerate IAM roles in order to determine if a
-role exists before attempting to assume or hijack the discovered role.
-"""
-from = "now-20m"
-index = ["filebeat-*", "logs-aws.cloudtrail-*"]
-language = "kuery"
-license = "Elastic License v2"
-name = "AWS IAM Brute Force of Assume Role Policy"
-note = """## Triage and analysis
-
-### Investigating AWS IAM Brute Force of Assume Role Policy
-
-An IAM role is an IAM identity that you can create in your account that has specific permissions. An IAM role is similar to an IAM user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session.
-
-Attackers may attempt to enumerate IAM roles in order to determine if a role exists before attempting to assume or hijack the discovered role.
-
-#### Possible investigation steps
-
-- Identify the user account that performed the action and whether it should perform this kind of action.
-- Verify if the `RoleName` parameter contains a unique value in all requests or if the activity is potentially a brute force attack.
-- Verify if the user account successfully updated a trust policy in the last 24 hours.
-- Examine whether this role existed in the environment by looking for past occurrences in your logs.
-- Investigate other alerts associated with the user account during the past 48 hours.
-- Contact the account and resource owners and confirm whether they are aware of this activity.
-- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?
-- Examine the account's commands, API calls, and data management actions in the last 24 hours.
-- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.
-
-### False positive analysis
-
-- Verify the roles targeted in the failed attempts, and whether the subject role previously existed in the environment. If only one role was targeted in the requests and that role previously existed, it may be a false positive, since automations can continue targeting roles that existed in the environment in the past and cause false positives (FPs).
-
-### Response and remediation
-
-- Initiate the incident response process based on the outcome of the triage.
-- Disable or limit the account during the investigation and response.
-- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
-    - Identify the account role in the cloud environment.
-    - Assess the criticality of affected services and servers.
-    - Work with your IT team to identify and minimize the impact on users.
-    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
-    - Identify any regulatory or legal ramifications related to this activity.
-- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
-- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.
-- Consider enabling multi-factor authentication for users.
-- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.
-- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.
-- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
-- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
-
-## Setup
-
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
-references = [
-    "https://www.praetorian.com/blog/aws-iam-assume-role-vulnerabilities",
-    "https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/",
-]
-risk_score = 47
-rule_id = "ea248a02-bc47-4043-8e94-2885b19b2636"
-severity = "medium"
-tags = [
-    "Domain: Cloud",
-    "Data Source: AWS",
-    "Data Source: Amazon Web Services",
-    "Use Case: Identity and Access Audit",
-    "Resources: Investigation Guide",
-    "Tactic: Credential Access",
-]
-timestamp_override = "event.ingested"
-type = "threshold"
-
-query = '''
-event.dataset:aws.cloudtrail and
-  event.provider:iam.amazonaws.com and event.action:UpdateAssumeRolePolicy and
-  aws.cloudtrail.error_code:MalformedPolicyDocumentException and event.outcome:failure
-'''
-
-
-[[rule.threat]]
-framework = "MITRE ATT&CK"
-[[rule.threat.technique]]
-id = "T1110"
-name = "Brute Force"
-reference = "https://attack.mitre.org/techniques/T1110/"
-
-
-[rule.threat.tactic]
-id = "TA0006"
-name = "Credential Access"
-reference = "https://attack.mitre.org/tactics/TA0006/"
-
-[rule.threshold]
-field = []
-value = 25
-

nldcsc_elastic_rules/rules/integrations/aws/discovery_ec2_multi_region_describe_instances.toml

@@ -1,135 +0,0 @@
-[metadata]
-creation_date = "2024/08/26"
-integration = ["aws"]
-maturity = "production"
-updated_date = "2025/07/16"
-
-[rule]
-author = ["Elastic"]
-description = """
-Identifies when a single AWS resource is making `DescribeInstances` API calls in more than 10 regions within a 30-second
-window. This could indicate a potential threat actor attempting to discover the AWS infrastructure across multiple
-regions using compromised credentials or a compromised instance. Adversaries may use this information to identify
-potential targets for further exploitation or to gain a better understanding of the target's infrastructure.
-"""
-false_positives = [
-    """
-    Legitimate use of the `DescribeInstances` API call by an AWS resource that requires information about instances in
-    multiple regions.
-    """,
-    "Scheduled tasks or scripts that require information about instances in multiple regions.",
-]
-from = "now-9m"
-language = "esql"
-license = "Elastic License v2"
-name = "AWS EC2 Multi-Region DescribeInstances API Calls"
-note = """## Triage and analysis
-
-### Investigating AWS EC2 Multi-Region DescribeInstances API Calls
-
-This rule detects instances where a single AWS resource makes `DescribeInstances` API calls in over 10 regions within a 30-second window. This could indicate an adversary using compromised credentials or an exploited resource to enumerate AWS infrastructure across multiple regions. Attackers often leverage multi-region enumeration to assess the overall cloud environment and find potential targets for further exploitation.
-
-#### Possible Investigation Steps
-
-- **Identify the Resource and Actor**:
-  - **Actor ARN**: Check `aws.cloudtrail.user_identity.arn` to determine the exact identity performing the enumeration. Validate if the user is expected to perform region-wide `DescribeInstances` actions across multiple regions or if it seems unusual.
-  - **Account and Role Details**: Examine `cloud.account.id` and `aws.cloudtrail.user_identity.session_context.session_issuer` for information about the AWS account and specific role associated with the action.
-
-- **Analyze API Call Patterns**:
-  - **Frequency and Scope**: Review `cloud.region` field and confirm if this specific resource commonly performs `DescribeInstances` calls across multiple regions.
-  - **Time Window Context**: Compare the timing of the API calls within the `target_time_window` to determine if this burst pattern aligns with expected system usage or is potentially malicious.
-
-- **Check User Agent and Tooling**:
-  - **Source and User Agent**: Verify `user_agent.original` to determine if the request was made through expected tooling (e.g., AWS CLI or SDK) or a third-party tool that might indicate non-standard access.
-  - **Source IP Address**: Look into `source.address` to identify the origin of the calls. Unusual IP addresses, especially those outside expected ranges, may indicate compromised access.
-
-- **Evaluate for Potential Reconnaissance Behavior**:
-  - **Account and Region Enumeration**: Adversaries may use region-wide `DescribeInstances` requests to discover resources within an account across different regions. Confirm if this access aligns with operational practices or represents excessive access.
-  - **Permissions and Roles**: Investigate the permissions associated with the user role. Excessive permissions on a compromised role may allow broader enumeration, which should be restricted.
-
-- **Review Related CloudTrail Events**:
-  - **Additional Describe or List Actions**: Identify any associated `Describe` or `List` API calls that may indicate further enumeration of other AWS services within the same timeframe.
-  - **Potential Preceding Events**: Look for preceding login or access events from the same actor, as these may indicate potential credential compromise or unauthorized escalation of privileges.
-
-### False Positive Analysis
-
-- **Expected Enumeration**: Certain administrative or automation scripts may conduct broad `DescribeInstances` API calls for inventory purposes. Review usage patterns or consult relevant teams to validate the purpose.
-- **Automated Cloud Management**: Some automated services may perform regional checks for compliance or backup operations. If this rule is triggered repeatedly by a known service, consider whitelisting or tuning accordingly.
-
-### Response and Remediation
-
-- **Review IAM Policies and Role Permissions**: Limit the permissions of roles associated with this resource, restricting unnecessary multi-region enumeration access.
-- **Enforce Least Privilege Access**: Ensure that permissions for DescribeInstances are tightly controlled and restricted to specific roles or accounts that require multi-region access.
-- **Increase Monitoring and Alerts**: Set up additional monitoring on this role or account for further signs of unauthorized activity or lateral movement attempts.
-- **Access Review**: Conduct a review of users and entities with `DescribeInstances` permissions, especially for multi-region capabilities, and ensure these permissions are necessary for their functions.
-
-### Additional Information
-
-For further information on AWS `DescribeInstances` permissions and best practices, refer to the [AWS DescribeInstances API documentation](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstances.html).
-"""
-references = [
-    "https://www.sentinelone.com/labs/exploring-fbot-python-based-malware-targeting-cloud-and-payment-services/",
-    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstances.html",
-]
-risk_score = 21
-rule_id = "393ef120-63d1-11ef-8e38-f661ea17fbce"
-severity = "low"
-tags = [
-    "Domain: Cloud",
-    "Data Source: AWS",
-    "Data Source: AWS EC2",
-    "Resources: Investigation Guide",
-    "Use Case: Threat Detection",
-    "Tactic: Discovery",
-]
-timestamp_override = "event.ingested"
-type = "esql"
-
-query = '''
-from logs-aws.cloudtrail-*
-
-// filter for DescribeInstances API calls
-| where event.dataset == "aws.cloudtrail"
-  and event.provider == "ec2.amazonaws.com"
-  and event.action == "DescribeInstances"
-
-// truncate the timestamp to a 30-second window
-| eval Esql.time_window_date_trunc = date_trunc(30 seconds, @timestamp)
-
-// keep only the relevant raw fields
-| keep Esql.time_window_date_trunc, aws.cloudtrail.user_identity.arn, cloud.region
-
-// count the number of unique regions and total API calls within the 30-second window
-| stats
-    Esql.cloud_region_count_distinct = count_distinct(cloud.region),
-    Esql.event_count = count(*)
-  by Esql.time_window_date_trunc, aws.cloudtrail.user_identity.arn
-
-// filter for resources making DescribeInstances API calls in more than 10 regions within the 30-second window
-| where Esql.cloud_region_count_distinct >= 10 and Esql.event_count >= 10
-
-// sort the results by time window in descending order
-| sort Esql.time_window_date_trunc desc
-'''
-
-[rule.investigation_fields]
-field_names = [
-  "aws.cloudtrail.user_identity.arn",
-  "target_time_window",
-  "region_count",
-  "window_count"
-]
-
-[[rule.threat]]
-framework = "MITRE ATT&CK"
-[[rule.threat.technique]]
-id = "T1580"
-name = "Cloud Infrastructure Discovery"
-reference = "https://attack.mitre.org/techniques/T1580/"
-
-
-[rule.threat.tactic]
-id = "TA0007"
-name = "Discovery"
-reference = "https://attack.mitre.org/tactics/TA0007/"
-

nldcsc_elastic_rules/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml

@@ -1,155 +0,0 @@
-[metadata]
-creation_date = "2024/11/04"
-integration = ["aws"]
-maturity = "production"
-updated_date = "2025/07/16"
-
-[rule]
-author = ["Elastic"]
-description = """
-Detects when a single AWS resource is running multiple `Describe` and `List` API calls in a 10-second window. This
-behavior could indicate an actor attempting to discover the AWS infrastructure using compromised credentials or a
-compromised instance. Adversaries may use this information to identify potential targets for further exploitation or to
-gain a better understanding of the target's infrastructure.
-"""
-false_positives = [
-    """
-    Administrators or automated systems may legitimately perform multiple `Describe` and `List` API calls in a short
-    time frame. Verify the user identity and the purpose of the API calls to determine if the behavior is expected.
-    """,
-]
-from = "now-9m"
-language = "esql"
-license = "Elastic License v2"
-name = "AWS Discovery API Calls via CLI from a Single Resource"
-note = """## Triage and analysis
-
-### Investigating AWS Discovery API Calls via CLI from a Single Resource
-
-This rule detects multiple discovery-related API calls (`Describe`, `List`, or `Get` actions) within a short time window (30 seconds) from a single AWS resource. High volumes of such calls may indicate attempts to enumerate AWS infrastructure for reconnaissance purposes, which is often a tactic used by adversaries with compromised credentials or unauthorized access.
-
-#### Possible Investigation Steps
-
-- **Identify the Actor and Resource**:
-  - **User Identity and Resource**: Examine `aws.cloudtrail.user_identity.arn` to identify the actor making the discovery requests. Verify the user or resource associated with these actions to ensure they are recognized and expected.
-  - **User Agent and Tooling**: Check `user_agent.name` to confirm whether the `aws-cli` tool was used for these requests. Use of the CLI in an atypical context might indicate unauthorized or automated access.
-
-- **Evaluate the Context and Scope of API Calls**:
-  - **API Action Types**: Look into the specific actions under `event.action` for API calls like `Describe*`, `List*`, or `Get*`. Note if these calls are targeting sensitive services, such as `EC2`, `IAM`, or `S3`, which may suggest an attempt to identify high-value assets.
-  - **Time Pattern Analysis**: Review the `time_window` and `unique_api_count` to assess whether the frequency of these calls is consistent with normal patterns for this resource or user.
-
-- **Analyze Potential Compromise Indicators**:
-  - **Identity Type**: Review `aws.cloudtrail.user_identity.type` to determine if the calls originated from an assumed role, a root user, or a service role. Unusual identity types for discovery operations may suggest misuse or compromise.
-  - **Source IP and Geographic Location**: Examine the `source.ip` and `source.geo` fields to identify any unusual IP addresses or locations associated with the activity, which may help confirm or rule out external access.
-
-- **Examine Related CloudTrail Events**:
-  - **Pivot for Related Events**: Identify any additional IAM or CloudTrail events tied to the same actor ARN. Activities such as `AssumeRole`, `GetSessionToken`, or `CreateAccessKey` in proximity to these discovery calls may signal an attempt to escalate privileges.
-  - **Look for Anomalous Patterns**: Determine if this actor or resource has performed similar discovery actions previously, or if these actions coincide with other alerts related to credential use or privilege escalation.
-
-### False Positive Analysis
-
-- **Expected Discovery Activity**: Regular discovery or enumeration API calls may be conducted by security, automation, or monitoring scripts to maintain an inventory of resources. Validate if this activity aligns with known automation or inventory tasks.
-- **Routine Admin or Automated Access**: If specific roles or resources, such as automation tools or monitoring services, regularly trigger this rule, consider adding exceptions for these known, benign users to reduce false positives.
-
-### Response and Remediation
-
-- **Confirm Authorized Access**: If the discovery activity appears unauthorized, consider immediate steps to restrict the user or resource’s permissions.
-- **Review and Remove Unauthorized API Calls**: If the actor is not authorized to perform discovery actions, investigate and potentially disable their permissions or access keys to prevent further misuse.
-- **Enhance Monitoring for Discovery Patterns**: Consider additional logging or alerting for high-frequency discovery API calls, especially if triggered from new or unrecognized resources.
-- **Policy Review and Updates**: Review IAM policies associated with the actor, ensuring restrictive permissions and MFA enforcement where possible to prevent unauthorized discovery.
-
-### Additional Information
-
-For further guidance on AWS infrastructure discovery and best practices, refer to [AWS CloudTrail documentation](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference.html) and MITRE ATT&CK’s [Cloud Infrastructure Discovery](https://attack.mitre.org/techniques/T1580/).
-"""
-references = ["https://stratus-red-team.cloud/attack-techniques/AWS/aws.discovery.ec2-enumerate-from-instance/"]
-risk_score = 21
-rule_id = "74f45152-9aee-11ef-b0a5-f661ea17fbcd"
-severity = "low"
-tags = [
-    "Domain: Cloud",
-    "Data Source: AWS",
-    "Data Source: AWS EC2",
-    "Data Source: AWS IAM",
-    "Data Source: AWS S3",
-    "Use Case: Threat Detection",
-    "Tactic: Discovery",
-    "Resources: Investigation Guide",
-]
-timestamp_override = "event.ingested"
-type = "esql"
-
-query = '''
-from logs-aws.cloudtrail*
-
-// create time window buckets of 10 seconds
-| eval Esql.time_window_date_trunc = date_trunc(10 seconds, @timestamp)
-| where
-    event.dataset == "aws.cloudtrail"
-
-    // filter on CloudTrail audit logs for IAM, EC2, S3, etc.
-    and event.provider in (
-      "iam.amazonaws.com",
-      "ec2.amazonaws.com",
-      "s3.amazonaws.com",
-      "rds.amazonaws.com",
-      "lambda.amazonaws.com",
-      "dynamodb.amazonaws.com",
-      "kms.amazonaws.com",
-      "cloudfront.amazonaws.com",
-      "elasticloadbalancing.amazonaws.com"
-    )
-
-    // ignore AWS service actions
-    and aws.cloudtrail.user_identity.type != "AWSService"
-
-    // filter for aws-cli specifically
-    and user_agent.name == "aws-cli"
-
-    // exclude DescribeCapacityReservations events related to AWS Config
-    and not event.action in ("DescribeCapacityReservations")
-
-// filter for Describe, Get, List, and Generate API calls
-| where true in (
-    starts_with(event.action, "Describe"),
-    starts_with(event.action, "Get"),
-    starts_with(event.action, "List"),
-    starts_with(event.action, "Generate")
-)
-
-// extract owner, identity type, and actor from the ARN
-| dissect aws.cloudtrail.user_identity.arn "%{}::%{Esql_priv.aws_cloudtrail_user_identity_arn_owner}:%{Esql.aws_cloudtrail_user_identity_arn_type}/%{Esql.aws_cloudtrail_user_identity_arn_roles}"
-| where starts_with(Esql.aws_cloudtrail_user_identity_arn_roles, "AWSServiceRoleForConfig") != true
-
-// keep relevant fields (preserving ECS fields and computed time window)
-| keep @timestamp, Esql.time_window_date_trunc, event.action, aws.cloudtrail.user_identity.arn
-
-// count the number of unique API calls per time window and actor
-| stats
-    Esql.event_action_count_distinct = count_distinct(event.action)
-  by Esql.time_window_date_trunc, aws.cloudtrail.user_identity.arn
-
-// filter for more than 5 unique API calls per 10s window
-| where Esql.event_action_count_distinct > 5
-
-// sort the results by the number of unique API calls in descending order
-| sort Esql.event_action_count_distinct desc
-'''
-
-
-[[rule.threat]]
-framework = "MITRE ATT&CK"
-[[rule.threat.technique]]
-id = "T1580"
-name = "Cloud Infrastructure Discovery"
-reference = "https://attack.mitre.org/techniques/T1580/"
-
-
-[rule.threat.tactic]
-id = "TA0007"
-name = "Discovery"
-reference = "https://attack.mitre.org/tactics/TA0007/"
-
-[rule.investigation_fields]
-field_names = ["time_window", "aws.cloudtrail.user_identity.arn", "unique_api_count"]
-

nldcsc_elastic_rules/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml

@@ -1,95 +0,0 @@
-[metadata]
-creation_date = "2021/08/27"
-integration = ["aws"]
-maturity = "production"
-updated_date = "2025/01/15"
-
-[rule]
-author = ["Austin Songer"]
-description = """
-Detects when an EFS File System or Mount is deleted. An adversary could break any file system using the mount target
-that is being deleted, which might disrupt instances or applications using those mounts. The mount must be deleted prior
-to deleting the File System, or the adversary will be unable to delete the File System.
-"""
-false_positives = [
-    """
-    File System or Mount being deleted may be performed by a system administrator. Verify whether the user identity,
-    user agent, and/or hostname should be making changes in your environment. File System Mount deletion by unfamiliar
-    users 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 EFS File System or Mount 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 AWS EFS File System or Mount Deleted
-
-Amazon Elastic File System (EFS) provides scalable file storage for use with AWS cloud services and on-premises resources. Adversaries may target EFS by deleting file systems or mount targets, disrupting applications reliant on these resources. The detection rule monitors AWS CloudTrail logs for successful deletion events, signaling potential malicious activity aimed at data destruction or service disruption.
-
-### Possible investigation steps
-
-- Review the AWS CloudTrail logs to identify the user or role associated with the deletion event by examining the user identity information in the logs.
-- Check the event time and correlate it with other activities in the AWS environment to determine if there are any related suspicious actions or patterns.
-- Investigate the source IP address and location from which the deletion request was made to assess if it aligns with expected access patterns or if it appears anomalous.
-- Verify if there were any recent changes to IAM policies or roles that might have inadvertently granted permissions to delete EFS resources.
-- Assess the impact of the deletion by identifying which applications or services were using the deleted EFS file system or mount target and determine if there are any disruptions.
-- Contact the user or team responsible for the AWS account to confirm if the deletion was intentional and authorized, or if it was potentially malicious.
-
-### False positive analysis
-
-- Routine maintenance activities by system administrators may trigger deletion events. To manage this, create exceptions for known maintenance windows or specific administrator accounts.
-- Automated scripts or cloud management tools that manage EFS resources might delete mounts or file systems as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts.
-- Development or testing environments often involve frequent creation and deletion of resources. Exclude these environments from the rule to prevent unnecessary alerts.
-- Scheduled cleanup jobs that remove unused or temporary file systems can cause false positives. Document these jobs and configure exceptions based on their execution schedule.
-- Ensure that any third-party services or integrations with AWS that manage EFS resources are accounted for, and their actions are excluded if they are part of expected behavior.
-
-### Response and remediation
-
-- Immediately isolate the affected EFS file system to prevent further unauthorized deletions or access. This can be done by modifying the security group rules to deny all traffic temporarily.
-- Review AWS CloudTrail logs to identify the source of the deletion request, including the IAM user or role involved, and assess whether the action was authorized.
-- Revoke or adjust permissions for the identified IAM user or role to prevent further unauthorized actions. Ensure that least privilege principles are applied.
-- Restore the deleted EFS file system or mount from the most recent backup, if available, to minimize data loss and service disruption.
-- Notify the incident response team and relevant stakeholders about the incident for further investigation and to ensure awareness across the organization.
-- Conduct a post-incident review to identify any gaps in security controls or processes that allowed the unauthorized deletion, and implement necessary improvements.
-- Enhance monitoring and alerting for similar events by ensuring that all critical AWS resources have appropriate logging and alerting configured, focusing on deletion and modification actions.
-
-## 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/efs/latest/ug/API_DeleteFileSystem.html",
-    "https://docs.aws.amazon.com/efs/latest/ug/API_DeleteMountTarget.html",
-]
-risk_score = 47
-rule_id = "536997f7-ae73-447d-a12d-bff1e8f5f0a0"
-severity = "medium"
-tags = ["Domain: Cloud", "Data Source: AWS", "Data Source: Amazon Web Services", "Tactic: Impact", "Resources: Investigation Guide"]
-timestamp_override = "event.ingested"
-type = "query"
-
-query = '''
-event.dataset:aws.cloudtrail and event.provider:elasticfilesystem.amazonaws.com and
-event.action:(DeleteMountTarget or DeleteFileSystem) and event.outcome:success
-'''
-
-
-[[rule.threat]]
-framework = "MITRE ATT&CK"
-[[rule.threat.technique]]
-id = "T1485"
-name = "Data Destruction"
-reference = "https://attack.mitre.org/techniques/T1485/"
-
-
-[rule.threat.tactic]
-id = "TA0040"
-name = "Impact"
-reference = "https://attack.mitre.org/tactics/TA0040/"
-