Elastic rules: 1l

[metadata]
creation_date = "2021/10/18"
integration = ["system", "windows"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
Identifies an attempt to reset a potentially privileged account password remotely. Adversaries may manipulate account
passwords to maintain access or evade password duration policies and preserve compromised credentials.
"""
false_positives = ["Legitimate remote account administration."]
from = "now-9m"
index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
language = "eql"
license = "Elastic License v2"
name = "Account Password Reset Remotely"
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 Account Password Reset Remotely

Remote password resets are crucial for managing user accounts, especially for privileged users. However, adversaries exploit this by resetting passwords to maintain unauthorized access or bypass security policies. The detection rule identifies suspicious remote password resets by monitoring successful network logins and subsequent password reset actions, focusing on privileged accounts to minimize noise and highlight potential threats.

### Possible investigation steps

- Review the source IP address from the authentication event to determine if it is from a known or trusted network. Investigate any unfamiliar or suspicious IP addresses.
- Check the winlog.event_data.TargetUserName from the password reset event to confirm if it belongs to a privileged account and verify if the reset was authorized.
- Correlate the winlog.event_data.SubjectLogonId from both the authentication and password reset events to ensure they are linked and identify the user or process responsible for the actions.
- Investigate the timing and frequency of similar events to identify patterns or anomalies that may indicate malicious activity.
- Examine any recent changes or activities associated with the account in question to assess if there are other signs of compromise or unauthorized access.

### False positive analysis

- Routine administrative tasks can trigger false positives when legitimate IT staff reset passwords for maintenance or support. To manage this, create exceptions for known IT personnel or service accounts that frequently perform these actions.
- Automated scripts or tools used for account management might cause false alerts. Identify and exclude these scripts or tools by their specific account names or IP addresses.
- Scheduled password resets for compliance or security policies may appear suspicious. Document and exclude these scheduled tasks by their timing and associated accounts.
- Service accounts with naming conventions similar to privileged accounts might be flagged. Review and adjust the rule to exclude these specific service accounts by refining the naming patterns in the query.
- Internal network devices or systems that perform regular password resets could be misinterpreted as threats. Whitelist these devices by their IP addresses or hostnames to reduce noise.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
- Revoke any active sessions associated with the compromised account to disrupt any ongoing malicious activities.
- Reset the password of the affected account using a secure method, ensuring it is done from a trusted and secure system.
- Conduct a thorough review of recent account activities and system logs to identify any additional unauthorized changes or access attempts.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.
- Implement additional monitoring on the affected account and related systems to detect any further suspicious activities.
- Review and update access controls and privileged account management policies to prevent similar incidents in the future.

## Performance
This rule may cause medium to high performance impact due to logic scoping all remote Windows logon activity.
"""

setup = """## Setup

The following Windows audit policies must be enabled to generate the events used by this rule:
- [Audit Logon](https://ela.st/audit-logon)
- [Audit User Account Management](https://ela.st/audit-user-account-management)
"""

references = [
    "https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4724",
    "https://stealthbits.com/blog/manipulating-user-passwords-with-mimikatz/",
    "https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES/blob/master/Credential%20Access/remote_pwd_reset_rpc_mimikatz_postzerologon_target_DC.evtx",
    "https://www.elastic.co/security-labs/detect-credential-access",
]
risk_score = 47
rule_id = "2820c9c2-bcd7-4d6e-9eba-faf3891ba450"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Impact",
    "Data Source: Windows Security Event Logs",
    "Resources: Investigation Guide",
]
type = "eql"

query = '''
sequence by winlog.computer_name with maxspan=1m
  [authentication where host.os.type == "windows" and event.action == "logged-in" and
    /* event 4624 need to be logged */
    winlog.logon.type : "Network" and event.outcome == "success" and source.ip != null and
    source.ip != "127.0.0.1" and source.ip != "::1" and
    not winlog.event_data.TargetUserName : ("svc*", "PIM_*", "_*_", "*-*-*", "*$")] by winlog.event_data.TargetLogonId
   /* event 4724 need to be logged */
  [iam where host.os.type == "windows" and event.action == "reset-password" and
   (
    /*
       This rule is very noisy if not scoped to privileged accounts, duplicate the
       rule and add your own naming convention and accounts of interest here.
     */
    winlog.event_data.TargetUserName: ("*Admin*", "*super*", "*SVC*", "*DC0*", "*service*", "*DMZ*", "*ADM*") or
    winlog.event_data.TargetSid : ("S-1-5-21-*-500", "S-1-12-1-*-500")
    )
  ] by winlog.event_data.SubjectLogonId
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"


[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1531"
name = "Account Access Removal"
reference = "https://attack.mitre.org/techniques/T1531/"


[rule.threat.tactic]
id = "TA0040"
name = "Impact"
reference = "https://attack.mitre.org/tactics/TA0040/"

[metadata]
creation_date = "2025/11/19"
maturity = "production"
updated_date = "2026/07/21"

[rule]
author = ["Elastic"]
description = """
This rule correlates medium-or-higher severity alerts involving the same host from at least two distinct detection rules
mapped to three or more ATT&CK tactics. Analysts can use this to prioritize triage and response, as this combination may
indicate host compromise.
"""
from = "now-8h"
interval = "1h"
language = "esql"
license = "Elastic License v2"
name = "Alerts in Different ATT&CK Tactics by Host"
risk_score = 73
rule_id = "29531d20-0e80-41d4-9ec6-d6b58e4a475c"
severity = "high"
tags = ["Use Case: Threat Detection", "Rule Type: Higher-Order Rule", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from .alerts-security.*  metadata _id

// filter for medium-or-higher severity alerts, excluding threat_match, machine_learning, and deprecated rules.
| where kibana.alert.risk_score > 21 and
        kibana.alert.rule.name IS NOT NULL and kibana.alert.rule.rule_id IS NOT NULL and
        host.id is not null and event.dataset is not null and
        kibana.alert.rule.type not in ("threat_match", "machine_learning") and
        // Exclude a deprecated rule whose alert name does not carry the standard prefix
        kibana.alert.rule.name != "Potential PrintNightmare File Modification" and
        not kibana.alert.rule.name like "Deprecated - *" and
        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)

// extract unique counts and values by host.id
| stats Esql.alerts_count = COUNT(*),
        Esql.kibana_alert_rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),
        Esql.kibana_alert_rule_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.rule_id),
        Esql.event_module_values = VALUES(event.module),
        Esql.host_name_values = VALUES(host.name),
        Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name),
        Esql.kibana_alert_rule_id_values = VALUES(kibana.alert.rule.rule_id),
        Esql.threat_tactic_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.threat.tactic.id),
        Esql.threat_tactic_name_values = VALUES(kibana.alert.rule.threat.tactic.name),
        Esql.process_executable_values = VALUES(process.executable),
        Esql.process_parent_executable_values = VALUES(process.parent.executable),
        Esql.process_command_line_values = VALUES(process.command_line),
        Esql.process_entity_id_distinct_count = COUNT_DISTINCT(process.entity_id) by host.id

// filter for risky hosts with multiple distinct rules across multiple tactics
// Distinct rule IDs prevent one rule mapped to multiple tactics from satisfying the correlation.
| where Esql.kibana_alert_rule_name_distinct_count >= 2 and
        Esql.kibana_alert_rule_id_distinct_count >= 2 and
        Esql.threat_tactic_id_distinct_count >= 3

// Populate the native host name for alert triage without changing the host.id correlation key.
| eval host.name = MV_FIRST(Esql.host_name_values)

// fields populated in the resulting alert
| keep host.id,
       host.name,
       Esql.alerts_count,
       Esql.kibana_alert_rule_name_distinct_count,
       Esql.kibana_alert_rule_id_distinct_count,
       Esql.process_entity_id_distinct_count,
       Esql.event_module_values,
       Esql.host_name_values,
       Esql.kibana_alert_rule_name_values,
       Esql.kibana_alert_rule_id_values,
       Esql.threat_tactic_name_values,
       Esql.process_executable_values,
       Esql.process_parent_executable_values,
       Esql.process_command_line_values
'''
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 Alerts in Different ATT&CK Tactics by Host

The rule identifies hosts with alerts across multiple ATT&CK tactics, which may indicate compromise. It helps analysts focus on high-risk hosts by correlating diverse alerts. The resulting alert is grouped, so the `Esql.*_values` fields summarize contributing alerts without preserving event order or relationships between values.

### Possible investigation steps

- Review the alert details to identify the specific host involved and the different ATT&CK tactics that triggered the alerts.
- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.
- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary.
- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.
- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.

### False positive analysis

- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance.
- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise.
- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening.
- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score.
- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities.

### Response and remediation

- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.
- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.
- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign."""

[rule.investigation_fields]
field_names = [
    "host.name",
    "host.id",
    "Esql.threat_tactic_name_values",
    "Esql.kibana_alert_rule_name_values",
    "Esql.alerts_count",
]

[metadata]
creation_date = "2020/11/17"
integration = ["google_workspace"]
maturity = "production"
updated_date = "2026/07/08"

[rule]
author = ["Elastic"]
description = """
Detects when an administrator adds a Google Workspace Marketplace application to the domain. Adversaries with
administrative access may register a malicious OAuth application to establish long-lived API access to mail, drive, and
other Workspace data, maintaining persistence and enabling collection without relying on a single user password alone.
"""
false_positives = [
    """
    Applications can be added to a Google Workspace domain by system administrators. Verify that the configuration
    change was expected. Exceptions can be added to this rule to filter expected behavior.
    """,
]
from = "now-130m"
index = ["filebeat-*", "logs-google_workspace.admin-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "Application Added to Google Workspace Domain"
note = """## Triage and analysis

### Investigating Application Added to Google Workspace Domain

Google Workspace Marketplace applications can request OAuth scopes to read or modify tenant data. When an administrator
adds an application at the domain level, users may be able to install or authorize it broadly, creating a durable
third-party access path. Threat actors with admin rights may add an adversary-controlled app to maintain API-based
persistence and access sensitive resources at scale.

This rule identifies when an administrator adds a Marketplace application via the `ADD_APPLICATION` event in the
`google_workspace.admin` data stream.

### Possible investigation steps

- Identify the initiating (actor) administrator by reviewing `user.email` or `user.name`, and note `@timestamp`.
- Identify the application added by reviewing `google_workspace.admin.application.name` and related application metadata in the raw event.
- Determine whether the change is expected and authorized:
  - Validate there is an approved change request or vendor onboarding record for the application.
  - If the actor account is unusual, treat the alert as higher priority until proven benign.
- Review Marketplace apps in the Google Admin console:
  - Navigate to Apps > Google Workspace Marketplace apps.
  - Confirm whether the application is allowed domain-wide or for specific organizational units, and review requested API scopes against least-privilege expectations.
- Search Kibana for related admin and OAuth activity:
  - Find other Marketplace changes by the same actor:
    ```
    data_stream.dataset: "google_workspace.admin" and user.email: "<ACTOR_EMAIL>" and event.action: ("ADD_APPLICATION" or "REMOVE_APPLICATION")
    ```
  - After the add, review OAuth authorizations that may indicate users or admins granting access to the app:
    ```
    data_stream.dataset: "google_workspace.token" and event.action: "authorize"
    ```
  - Scope for other security-weakening admin actions from the same `user.email` within the last 48 hours, such as Marketplace restriction changes, blocklist removals, or role assignments.

### False positive analysis

- Verify the application is an approved business tool with documented vendor risk review and scope justification.
- New application rollouts during migrations or acquisitions can trigger this rule, validate timing against change windows.

### Response and remediation

- Initiate the incident response process based on triage findings.
- If the add is not clearly authorized, remove or block the application under Google Workspace Marketplace apps while the investigation proceeds.
- Revoke OAuth tokens for the application client if users have already authorized it (`Security` > Access and data control > API controls, or user token review in admin reports).
- If the initiating admin account is suspected compromised, reset credentials, revoke active sessions, and review delegated admin roles assigned to that account.
- 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.
- Review the permissions assigned to the implicated administrator to ensure that the least privilege principle is being followed.
- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google.
- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).

## Setup

The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.

### Important Information Regarding Google Workspace Event Lag Times
- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs.
- This rule is configured to run every 10 minutes with a lookback time of 130 minutes.
- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m).
- See the following references for further information:
  - https://support.google.com/a/answer/7061566
  - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html"""
references = [
    "https://support.google.com/a/answer/6328701?hl=en#",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two",
]
risk_score = 73
rule_id = "785a404b-75aa-4ffd-8be5-3334a5a544dd"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: Google Workspace",
    "Use Case: Configuration Audit",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:google_workspace.admin and event.action:ADD_APPLICATION
'''


[[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.investigation_fields]
field_names = [
    "user.name",
    "user.email",
    "user.domain",
    "event.action",
    "google_workspace.admin.application.name",
    "google_workspace.admin.application.enabled",
]

[metadata]
creation_date = "2024/05/02"
integration = ["aws_bedrock"]
maturity = "production"
updated_date = "2025/11/10"

[rule]
author = ["Elastic"]
description = """
Identifies multiple violations of AWS Bedrock guardrails within a single request, resulting in a block action,
increasing the likelihood of malicious intent. Multiple violations implies that a user may be intentionally attempting
to cirvumvent security controls, access sensitive information, or possibly exploit a vulnerability in the system.
"""
false_positives = ["Legitimate misunderstanding by users or overly strict policies"]
from = "now-60m"
interval = "10m"
language = "esql"
license = "Elastic License v2"
name = "AWS Bedrock Guardrails Detected Multiple Policy Violations Within a Single Blocked Request"
note = """## Triage and analysis

### Investigating AWS Bedrock Guardrails Detected Multiple Policy Violations Within a Single Blocked Request

Amazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications.

It enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices.

Through Guardrail, organizations can define "denied topics" to prevent the model from generating content on specific, undesired subjects,
and they can establish thresholds for harmful content categories, including hate speech, violence, or offensive language.

#### Possible investigation steps

- Identify the user account and the user request that caused multiple policy violations and whether it should perform this kind of action.
- Investigate the user activity that might indicate a potential brute force attack.
- Investigate other alerts associated with the user account during the past 48 hours.
- 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 prompts and responses in the last 24 hours.
- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.

### False positive analysis

- Verify the user account that caused multiple policy violations, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails.

### 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.
    - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.
    - Identify any regulatory or legal ramifications related to this activity.
- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.
- 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).
"""
references = [
    "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html",
    "https://atlas.mitre.org/techniques/AML.T0051",
    "https://atlas.mitre.org/techniques/AML.T0054",
    "https://www.elastic.co/security-labs/elastic-advances-llm-security",
]
risk_score = 21
rule_id = "f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c"
setup = """## Setup

This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:

https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html
"""
severity = "low"
tags = [
    "Domain: LLM",
    "Data Source: AWS Bedrock",
    "Data Source: AWS S3",
    "Resources: Investigation Guide",
    "Use Case: Policy Violation",
    "Mitre Atlas: T0051",
    "Mitre Atlas: T0054",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-aws_bedrock.invocation-*

// Expand multi-value policy action field
| mv_expand gen_ai.policy.action

// Filter for policy-blocked requests
| where gen_ai.policy.action == "BLOCKED"

// count number of policy matches per request (multi-valued)
| eval Esql.ml_policy_violations_mv_count = mv_count(gen_ai.policy.name)

// Filter for requests with more than one policy match
| where Esql.ml_policy_violations_mv_count > 1

// keep relevant fields
| keep
  gen_ai.policy.action,
  Esql.ml_policy_violations_mv_count,
  user.id,
  gen_ai.request.model.id,
  cloud.account.id

// Aggregate requests with multiple violations
| stats
    Esql.ml_policy_violations_total_unique_requests_count = count(*)
  by
    Esql.ml_policy_violations_mv_count,
    user.id,
    gen_ai.request.model.id,
    cloud.account.id

// sort by number of unique requests
| sort Esql.ml_policy_violations_total_unique_requests_count desc
'''

[metadata]
creation_date = "2025/03/13"
integration = ["aws"]
maturity = "production"
updated_date = "2026/07/08"

[rule]
author = ["Elastic"]
description = """
Identifies when an AWS DynamoDB table is exported to S3. Adversaries may use the ExportTableToPointInTime operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the ExportTableToPointInTime action in CloudTrail logs. This is a New Terms rule that only flags when this behavior is observed by a user or role for the first time.
"""
false_positives = [
    """
    Legitimate users may export DynamoDB tables for various reasons, such as data analysis or backup purposes. Ensure that the user has the necessary permissions and that the ExportTableToPointInTime operation is authorized before taking action.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS DynamoDB Table Exported to S3"
note = """ ## Triage and analysis

### Investigating AWS DynamoDB Table Exported to S3

This rule identifies when an AWS DynamoDB table is exported to S3. Adversaries may use the ExportTableToPointInTime operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the ExportTableToPointInTime action in CloudTrail logs.

This is a New Terms rule that only flags when this behavior is observed for the first time.

#### Possible Investigation Steps
- Identify the Actor: Review the `aws.cloudtrail.user_identity.arn` field to identify the user who requested the export. Verify if this actor typically performs such actions and has the necessary permissions. It may be unusual for this activity to originate from certain user types, such as an assumed role or federated user.
- Review the Source IP: Check the `source.ip` field to determine the source of the request. If the request comes from an unexpected location or IP address, it may indicate a compromised account or unauthorized access.
- Review Access Key: Check the `aws.cloudtrail.user_identity.access_key_id` field to identify the access key used for the request. Determine if this key has been compromised.
- Analyze the Request Parameters: Examine the `aws.cloudtrail.request_parameters` field to understand the details of the ExportTableToPointInTime request. Look for any unusual parameters or patterns that may indicate malicious intent. This also details the DynamoDB table being exported.

### False Positive Analysis
- Historical User Actions: If the user has a history of exporting DynamoDB tables for legitimate purposes, this may be a false positive. Review the user's activity logs to determine if this behavior is consistent with their normal actions.
- Automated Processes: Some automated processes or applications may perform exports on DynamoDB tables as part of their functionality. If the user is associated with such a process, this may be a false positive.

### Response and Remediation
- Immediate Review and Reversal: If the ExportTableToPointInTime action is determined to be unauthorized, immediately revoke the user's access to the DynamoDB table and any associated resources. This may involve disabling the user's access keys or removing their permissions.
- Investigate Compromise: If the ExportTableToPointInTime action is determined to be malicious, investigate the source and destination of the request and any potential compromise of the user's account. If the destination S3 bucket is not known, it may be a sign of data exfiltration and may require incident response.
- Review IAM Policies: Review the IAM policies associated with the user to ensure that they have the appropriate permissions for their role. If necessary, update the policies to restrict access to sensitive resources.
- Monitor for Future Activity: Continue to monitor the user's activity for any further suspicious behavior. Set up additional alerts or logging to detect any future unauthorized access attempts.

### Additional Information

For further guidance on managing and securing DynamoDB in AWS environments, refer to the [AWS DynamoDB documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/security.html) and AWS best practices for security.
"""
references = ["https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ExportTableToPointInTime.html"]
risk_score = 73
rule_id = "e8ea6f58-0040-11f0-a243-f661ea17fbcd"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS DynamoDB",
    "Resources: Investigation Guide",
    "Use Case: Threat Detection",
    "Tactic: Exfiltration",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "dynamodb.amazonaws.com"
    and event.action: "ExportTableToPointInTime"
    and event.outcome: "success"
'''


[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1567"
name = "Exfiltration Over Web Service"
reference = "https://attack.mitre.org/techniques/T1567/"

[[rule.threat.technique.subtechnique]]
id = "T1567.002"
name = "Exfiltration to Cloud Storage"
reference = "https://attack.mitre.org/techniques/T1567/002/"

[rule.threat.tactic]
id = "TA0010"
name = "Exfiltration"
reference = "https://attack.mitre.org/tactics/TA0010/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1213"
name = "Data from Information Repositories"
reference = "https://attack.mitre.org/techniques/T1213/"

[rule.threat.tactic]
id = "TA0009"
name = "Collection"
reference = "https://attack.mitre.org/tactics/TA0009/"
[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",
    "aws.cloudtrail.resources.arn",     
    "aws.cloudtrail.resources.type",   
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters"
]

[rule.new_terms]
field = "new_terms_fields"
value = ["cloud.account.id", "user.name"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-10d"

[metadata]
creation_date = "2024/07/20"
integration = ["aws"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
This rule looks for use of the IAM `AttachUserPolicy` API operation to attach the `CompromisedKeyQuarantine` or `CompromisedKeyQuarantineV2` AWS managed policies to an existing IAM user.
This policy denies access to certain actions and is applied by the AWS team in the event that an IAM user's credentials have been compromised or exposed publicly.
"""
false_positives = [
    """
    This is an intentional action taken by AWS in the event of compromised credentials. Follow the instructions specified in the support case created for you regarding this event.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "eql"
license = "Elastic License v2"
name = "AWS IAM CompromisedKeyQuarantine Policy Attached to User"
note = """
## Triage and analysis

### Investigating AWS IAM CompromisedKeyQuarantine Policy Attached to User

The AWS IAM `CompromisedKeyQuarantine` and `CompromisedKeyQuarantineV2` managed policies deny certain action and is applied by the AWS team to a user with exposed credentials.
This action is accompanied by a support case which specifies instructions to follow before detaching the policy.

#### Possible Investigation Steps

- **Identify Potentially Compromised Identity**: Review the `userName` parameter of the `aws.cloudtrail.request_parameters` to determine the quarantined IAM entity.
- **Contextualize with AWS Support Case**: Review any information from AWS comtaining additional information about the quarantined account and the reasoning for quarantine.
- **Follow Support Case Instructions**: Do not revert the quarantine policy attachment or delete the compromised keys. Instead folow the instructions given in your support case.
- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in potentially suspicious activities.
- **Interview Relevant Personnel**: If the compromised key belongs to a user, verify the intent and authorization for these correlated actions with the person or team responsible for managing the compromised key.

### False Positive Analysis

- There shouldn't be many false positives related to this action as it is inititated by AWS in response to compromised or publicly exposed credentials.

### Response and Remediation

- **Immediate Review and Reversal**: Update the user IAM permissions to remove the quarantine policy and disable the compromised credentials.
- **Policy Update**: Review and possibly update your organization’s policies on credential storage to tighten control and prevent public exposure.
- **Incident Response**: If malicious intent is confirmed, consider it a data breach incident and initiate the incident response protocol. This includes further investigation, containment, and recovery.

### Additional Information:

For further guidance on managing and securing credentials in AWS environments, refer to the [AWS IAM User Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) regarding security best practices and guidance on [Remediating Potentially Compromised AWS Credentials](https://docs.aws.amazon.com/guardduty/latest/ug/compromised-creds.html).
"""
references = [
    "https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCompromisedKeyQuarantine.html/",
    "https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCompromisedKeyQuarantineV2.html/",
]
risk_score = 73
rule_id = "0b79f5c0-2c31-4fea-86cd-e62644278205"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS IAM",
    "Resources: Investigation Guide",
    "Use Case: Identity and Access Audit",
    "Tactic: Credential Access",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
iam where data_stream.dataset == "aws.cloudtrail"
   and event.action == "AttachUserPolicy"
   and event.outcome == "success"
   and stringContains(aws.cloudtrail.request_parameters, "AWSCompromisedKeyQuarantine")
'''

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1552"
name = "Unsecured Credentials"
reference = "https://attack.mitre.org/techniques/T1552/"

[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"

[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"

[rule.threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[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"
]

[metadata]
creation_date = "2024/06/27"
integration = ["aws"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies the modification of the master password for an AWS RDS DB instance or cluster. Changing the master password
is a legitimate recovery action when access is lost, but adversaries with sufficient permissions may modify it to regain
access, establish persistence, bypass existing controls, or escalate privileges within a compromised environment.
Because RDS does not expose the password in API responses, this operation can meaningfully alter access pathways to
sensitive data stores.
"""
event_category_override = "event.type"
false_positives = [
    """
    Master password modification may occur during legitimate administrative recovery (e.g., a lost password, rotation
    event, or Secrets Manager reassociation). Validate whether the change was expected, approved, and performed by
    authorized personnel. If known workflows routinely perform this action, consider adding targeted exceptions.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "eql"
license = "Elastic License v2"
name = "AWS RDS DB Instance or Cluster Password Modified"
note = """## Triage and analysis

### Investigating AWS RDS DB Instance or Cluster Password Modified

The RDS master user password controls privileged access to a database instance or cluster. Modifying it can immediately shift access from one operator to another, break application functionality, or allow an adversary to regain control over a compromised DB instance. Because RDS never returns the password via API, this operation is a strong signal of intentional access reconfiguration.

This rule detects successful password-modification events via `ModifyDBInstance` or `ModifyDBCluster`. Such changes may indicate credential loss recovery—or malicious actions related to persistence, privilege escalation, or defense evasion.

#### Possible investigation steps

- **Identify the actor and execution context**  
  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`.  
  - Inspect `user.name`, `source.ip`, and `user_agent.original` to determine whether the modification originated from expected networks, automation roles, or unusual sources.

- **Determine what was modified**  
  - Examine `aws.cloudtrail.request_parameters` to identify:  
    - The DB instance or cluster identifier.  
    - Whether other parameters were modified in the same call (e.g., `manageMasterUserPassword`, engine version, instance class, parameter group).  
  - Review instance metadata in AWS to understand the sensitivity level, environment (prod/stage/dev), and potential business impact.

- **Reconstruct timing and associated actions**  
  - Use `@timestamp` to compare the event against:  
    - Recent configuration changes such as `ModifyDBInstance`, `ModifyDBCluster`, or networking/security group updates.  
    - Other access-related operations (e.g., `AddRoleToDBInstance`, changes to Secrets Manager associations, disabling deletion protection).  
  - Check for signs of credential misuse leading up to the event (e.g., `DescribeDBInstances`, `GetCallerIdentity`, unauthorized console logins).

- **Correlate with broader activity**  
  - Pivot in CloudTrail using the same access key, principal ARN, or source IP.  
  - Look for:  
    - Privilege-escalating or persistence-related behavior (IAM policy changes, role modifications, STS session creation).  
    - Subsequent DB-impacting operations, such as snapshot deletion, backup retention changes, or cluster deletion.  
    - Evidence of data access anomalies (backup exports, data snapshot copies, cross-region actions).

- **Validate intent with operational owners**  
  - Confirm with DBAs, platform engineers, and application owners whether the password change:  
    - Was requested or scheduled.  
    - Aligns with pending migrations, credential rotations, or recovery actions.  
  - If not recognized, treat this as a high-risk event requiring deeper containment.

### False positive analysis

- **Recovery or maintenance tasks**  
  - Password resets occur during lost-credential scenarios or planned rotations. Confirm if this aligns with a documented workflow.
- **Secrets Manager integration changes**  
  - When `manageMasterUserPassword` is toggled or Secrets Manager rotates passwords, a modification event may occur. Validate whether an automation pipeline triggered the change.
- **Non-production workloads**  
  - Development or staging environments may see frequent password resets. Consider tuning exceptions based on tags, instance identifiers, or IAM roles tied to automation.

### Response and remediation

- **Contain unauthorized access**  
  - If activity is suspicious:  
    - Immediately rotate the master password again using a secure, validated workflow.  
    - Verify whether Secrets Manager integration was disabled (`manageMasterUserPassword=false`) and restore it if necessary.  
    - Restrict inbound DB access by tightening associated security group rules or isolating the instance temporarily.

- **Investigate surrounding activity**  
  - Review CloudTrail to identify:  
    - Who accessed the instance after the password change.  
    - Whether any destructive or data-exfiltrating RDS actions occurred.  
    - Other IAM or STS activity tied to the same user or session.

- **Restore guardrails and enhance monitoring**  
  - Ensure deletion protection, backup retention, and networking controls are correctly configured.  
  - Add real-time alerts for password-related modifications and high-risk RDS API actions.

- **Strengthen IAM and operational controls**  
  - Limit permissions for `rds:ModifyDBInstance` and `rds:ModifyDBCluster`, especially when modifying authentication parameters.  
  - Require MFA and role-based access for DB administrators.  
  - Tighten SCPs or Config rules to restrict unauthorized DB configuration changes.

### 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/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html",
    "https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html",
    "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc#rds-modifydbinstance",
]
risk_score = 47
rule_id = "f2015527-7c46-4bb9-80db-051657ddfb69"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS RDS",
    "Resources: Investigation Guide",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Privilege Escalation",
    "Tactic: Defense Evasion",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
info where data_stream.dataset == "aws.cloudtrail"
    and event.provider == "rds.amazonaws.com"
    and event.action in ("ModifyDBInstance", "ModifyDBCluster")
    and event.outcome == "success"
    and stringContains(aws.cloudtrail.request_parameters, "masterUserPassword=*")
'''


[[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.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"

[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[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",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
    "aws.cloudtrail.response_elements",
]

[metadata]
creation_date = "2020/09/01"
integration = ["azure"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Azure Active Directory (AD) Privileged Identity Management (PIM) is a service that enables you to manage, control, and
monitor access to important resources in an organization. PIM can be used to manage the built-in Azure resource roles
such as Global Administrator and Application Administrator. An adversary may add a user to a PIM role in order to
maintain persistence in their target's environment or modify a PIM role to weaken their target's security controls.
"""
from = "now-9m"
index = ["logs-azure.auditlogs-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID Privileged Identity Management (PIM) Role Modified"
note = """## Triage and analysis

### Investigating Entra ID Privileged Identity Management (PIM) Role Modified

Azure Active Directory (AD) Privileged Identity Management (PIM) is a service that enables you to manage, control, and monitor access to important resources in an organization. PIM can be used to manage the built-in Azure resource roles such as Global Administrator and Application Administrator.

This rule identifies the update of PIM role settings, which can indicate that an attacker has already gained enough access to modify role assignment settings.

#### Possible investigation steps

- Identify the user account that performed the action and whether it should perform this kind of action.
- Investigate other alerts associated with the user account during the past 48 hours.
- Consider the source IP address and geolocation for the user who issued the command. Do they look normal for the user?
- 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?
- Check if this operation was approved and performed according to the organization's change management policy.
- Contact the account owner and confirm whether they are aware of this activity.
- 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

- If this activity didn't follow your organization's change management policies, it should be reviewed by the security team.

### 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.
- Restore the PIM roles to the desired state.
- Consider enabling multi-factor authentication for users.
- Follow security best practices [outlined](https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices) by Microsoft.
- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).

## Setup

The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-resource-roles-assign-roles",
    "https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-configure",
]
risk_score = 47
rule_id = "7882cebf-6cf1-4de3-9662-213aa13e8b80"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: Azure",
    "Use Case: Identity and Access Audit",
    "Resources: Investigation Guide",
    "Tactic: Persistence",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:azure.auditlogs and azure.auditlogs.operation_name:"Update role setting in PIM" and event.outcome:(Success or success)
'''


[[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.003"
name = "Additional Cloud Roles"
reference = "https://attack.mitre.org/techniques/T1098/003/"

[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"

[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.003"
name = "Additional Cloud Roles"
reference = "https://attack.mitre.org/techniques/T1098/003/"

[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"

[metadata]
bypass_bbr_timing = true
creation_date = "2023/10/11"
integration = ["github"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = "Detects an interaction with a private GitHub repository from a new IP address not seen in the last 14 days.\n"
from = "now-9m"
index = ["logs-github.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "First Occurrence of GitHub Repo Interaction From a New IP"
risk_score = 21
rule_id = "0294f105-d7af-4a02-ae90-35f56763ffa2"
severity = "low"
tags = [
    "Domain: Cloud",
    "Use Case: Threat Detection",
    "Use Case: UEBA",
    "Tactic: Execution",
    "Rule Type: BBR",
    "Data Source: Github",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
event.dataset:"github.audit" and event.category:"configuration" and
github.actor_ip:* and github.repo:* and 
github.repository_public:false
'''


[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1648"
name = "Serverless Execution"
reference = "https://attack.mitre.org/techniques/T1648/"

[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1213"
name = "Data from Information Repositories"
reference = "https://attack.mitre.org/techniques/T1213/"

[[rule.threat.technique.subtechnique]]
id = "T1213.003"
name = "Code Repositories"
reference = "https://attack.mitre.org/techniques/T1213/003/"

[rule.threat.tactic]
id = "TA0009"
name = "Collection"
reference = "https://attack.mitre.org/tactics/TA0009/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"

[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"

[rule.threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[rule.new_terms]
field = "new_terms_fields"
value = ["github.repo", "github.actor_ip"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-5d"

[metadata]
creation_date = "2026/01/28"
integration = ["fortinet_fortigate"]
maturity = "production"
updated_date = "2026/05/06"

[rule]
author = ["Elastic"]
description = """
This rule detects the first observed successful login of a user with the Administrator role to the FortiGate management
interface within the last 5 days. First-time administrator logins can indicate newly provisioned accounts,
misconfigurations, or unauthorized access using valid credentials and should be reviewed promptly.
"""
from = "now-7205m"
interval = "5m"
language = "esql"
license = "Elastic License v2"
name = "First-Time FortiGate Administrator Login"
note = """## Triage and Analysis

### Investigating First-Time FortiGate Administrator Login

This alert indicates that a user with the **Administrator** role has successfully logged in to the FortiGate management interface for the first time within the last 5 days of observed data.

Because administrator access provides full control over network security devices, any newly observed admin login should be validated to confirm it is expected and authorized.

### Investigation Steps

- **Identify the account**
  - Review `source.user.name` and confirm whether the account is known and officially provisioned.
  - Determine whether this is a newly created administrator or an existing account logging in for the first time.

- **Validate the source**
  - Review `source.ip` and confirm whether it originates from a trusted management network, VPN, or jump host.
  - Investigate geolocation or ASN if the source IP is external or unusual.

- **Review login context**
  - Examine associated FortiGate log messages for details such as login method, interface, or authentication source.
  - Check for additional administrative actions following the login (policy changes, user creation, configuration exports).
  - Review  `fortinet.firewall.profile` to identify the FortiGate Admin Profile the identity logged in under.

- **Correlate with recent changes**
  - Verify whether there were recent change requests, onboarding activities, or maintenance windows that explain the login.
  - Look for other authentication attempts (failed or successful) from the same source or user.

### False Positive Considerations

- Newly onboarded administrators or service accounts.
- First-time logins after log retention changes or data source onboarding.
- Automation, backup, or monitoring tools introduced recently.
- Lab, development, or test FortiGate devices.

### Response and Remediation

- **If authorized**
  - Document the activity and consider adding an exception if the behavior is expected.
  - Ensure the account follows least-privilege and MFA best practices.

- **If suspicious or unauthorized**
  - Disable or restrict the administrator account immediately.
  - Rotate credentials and review authentication sources.
  - Audit recent FortiGate configuration changes.
  - Review surrounding network activity for lateral movement or persistence attempts."""
references = [
    "https://www.elastic.co/docs/reference/integrations/fortinet_fortigate",
    "https://www.cisa.gov/news-events/alerts/2026/01/28/fortinet-releases-guidance-address-ongoing-exploitation-authentication-bypass-vulnerability-cve-2026",
]
risk_score = 73
rule_id = "55a372b9-f5b6-4069-a089-8637c00609a2"
severity = "high"
tags = [
    "Use Case: Threat Detection",
    "Tactic: Initial Access",
    "Resources: Investigation Guide",
    "Domain: Network",
    "Domain: Identity",
    "Data Source: Fortinet",
    "Data Source: Fortinet FortiGate",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
FROM logs-fortinet_fortigate.*, filebeat-* metadata _id

| WHERE data_stream.dataset == "fortinet_fortigate.log" and
        event.category == "authentication" and event.action == "login" and
        event.outcome == "success" and source.user.roles == "Administrator" and source.user.name is not null
| stats Esql.logon_count = count(*),
       Esql.first_time_seen = MIN(@timestamp),
       Esql.source_ip_values = VALUES(source.ip),
       Esql.message_values = VALUES(message) by source.user.name, fortinet.firewall.profile

// first time seen is within 6m of the rule execution time and for the last 5d of events history
| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now())
| where Esql.recent <= 6 and Esql.logon_count == 1

// move dynamic fields to ECS equivalent for rule exceptions
| eval source.ip = MV_FIRST(Esql.source_ip_values)

| keep source.ip,
       source.user.name,
       fortinet.firewall.profile,
       Esql.logon_count,
       Esql.first_time_seen,
       Esql.source_ip_values,
       Esql.message_values,
       Esql.recent
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"


[rule.threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"

[metadata]
creation_date = "2025/12/04"
integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defender", "auditd_manager"]
maturity = "production"
updated_date = "2026/04/07"

[rule]
author = ["Elastic"]
description = """
Detects when GenAI tools spawn compilers or packaging tools to generate executables. Attackers leverage local LLMs to
autonomously generate and compile malware, droppers, or implants. Python packaging tools (pyinstaller, nuitka, pyarmor)
are particularly high-risk as they create standalone executables that can be deployed without dependencies. This rule
focuses on compilation activity that produces output binaries, filtering out inspection-only operations.
"""
from = "now-9m"
index = [
    "logs-endpoint.events.process-*",
    "logs-windows.sysmon_operational-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-auditd_manager.auditd-*",
]
language = "eql"
license = "Elastic License v2"
name = "GenAI Process Compiling or Generating Executables"
note = """## Triage and analysis

### Investigating GenAI Process Compiling or Generating Executables

This rule detects GenAI tools spawning compilers or packaging tools. While developers may use GenAI to write code that they then compile, autonomous compilation by GenAI processes is unusual.

### Possible investigation steps

- Review the GenAI process that spawned the compiler to identify which tool is running and verify if it's an expected/authorized tool.
- Investigate the user account associated with the GenAI process to determine if this activity is expected for that user.
- Review the output files created by the compilation process to identify any malicious executables.
- Check for other alerts or suspicious activity on the same host around the same time.
- Verify if the GenAI tool is from a trusted source and if it's authorized for use in your environment.
- Identify whether the generated executables appear in temporary directories often used for malware staging (`%TEMP%`, `/tmp`, `.cache`).
- Inspect the compiled artifacts for networking imports, credential harvesting functionality, or persistence mechanisms.

### False positive analysis

- Legitimate development workflows that use GenAI tools for code generation may trigger this rule if they compile the generated code.
- Some GenAI-assisted coding IDEs (Cursor, Copilot Workspace) may run compilation tasks when testing code; confirm whether the behavior is tied to developer workflow.

### Response and remediation

- Terminate the GenAI process and any spawned compiler processes to stop the malicious activity.
- Investigate the compiled executables to determine if they are malicious.
- Review audit logs to determine the scope of compilation activity and identify any executables that may have been created.
- Quarantine any compiled binaries; submit suspicious artifacts to sandbox or malware analysis.
"""
references = [
    "https://atlas.mitre.org/techniques/AML.T0053",
    "https://www.elastic.co/security-labs/elastic-advances-llm-security",
]
risk_score = 47
rule_id = "b2c3d4e5-f6a7-8901-bcde-f123456789ab"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "OS: macOS",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: Auditd Manager",
    "Data Source: Microsoft Defender XDR",
    "Data Source: SentinelOne",
    "Resources: Investigation Guide",
    "Domain: LLM",
    "Mitre Atlas: T0053",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where event.type == "start" and

  // GenAI parent process
  (
    process.parent.name in (
      "ollama.exe", "ollama", "Ollama",
      "textgen.exe", "textgen", "text-generation-webui.exe", "oobabooga.exe",
      "lmstudio.exe", "lmstudio", "LM Studio",
      "claude.exe", "claude", "Claude",
      "cursor.exe", "cursor", "Cursor", "Cursor Helper", "Cursor Helper (Plugin)",
      "copilot.exe", "copilot", "Copilot",
      "codex.exe", "codex",
      "Jan", "jan.exe", "jan", "Jan Helper",
      "gpt4all.exe", "gpt4all", "GPT4All",
      "gemini-cli.exe", "gemini-cli",
      "genaiscript.exe", "genaiscript",
      "grok.exe", "grok",
      "qwen.exe", "qwen",
      "koboldcpp.exe", "koboldcpp", "KoboldCpp",
      "llama-server", "llama-cli"
    ) or
    
    // Node/Deno with GenAI frameworks
    (process.parent.name in ("node.exe", "node", "deno.exe", "deno") and
     process.parent.command_line like~ ("*mcp-server*", "*@modelcontextprotocol*", "*langchain*", "*autogpt*", "*babyagi*", "*agentgpt*", "*crewai*", "*semantic-kernel*", "*llama-index*", "*haystack*")) or
    
    // Python with GenAI frameworks
    (process.parent.name like~ "python*" and
     process.parent.command_line like~ ("*langchain*", "*autogpt*", "*babyagi*", "*agentgpt*", "*crewai*", "*semantic-kernel*", "*llama-index*", "*haystack*"))
  ) and

  // Compilation tools
  (
    // Python packaging
    process.name in ("pyinstaller", "py2exe", "cx_Freeze", "nuitka", "pyarmor", "pkg") or
    
    // C/C++ compilation with output
    (process.name in ("gcc", "g++", "clang", "clang++", "cl.exe") and
     process.command_line like~ "*-o *" and
     process.command_line like~ ("*.c *", "*.c", "*.cpp *", "*.cpp", "*.cc *", "*.cc", "*.m *", "*.m") and
     not process.command_line like~ "*git*") or
    
    // Go compilation
    (process.name == "go" and process.args == "build") or
    
    // Rust compilation
    (process.name == "cargo" and process.args == "build") or
    (process.name == "rustc" and process.command_line like~ "*-o *") or
    
    // .NET compilation
    process.name in ("csc.exe", "vbc.exe", "msbuild.exe") or
    (process.name == "dotnet" and process.args == "build") or
    
    // Java compilation
    process.name == "javac"
  )
'''


[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1027"
name = "Obfuscated Files or Information"
reference = "https://attack.mitre.org/techniques/T1027/"

[[rule.threat.technique.subtechnique]]
id = "T1027.004"
name = "Compile After Delivery"
reference = "https://attack.mitre.org/techniques/T1027/004/"

[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 = "T1587"
name = "Develop Capabilities"
reference = "https://attack.mitre.org/techniques/T1587/"

[[rule.threat.technique.subtechnique]]
id = "T1587.001"
name = "Malware"
reference = "https://attack.mitre.org/techniques/T1587/001/"

[rule.threat.tactic]
id = "TA0042"
name = "Resource Development"
reference = "https://attack.mitre.org/tactics/TA0042/"

[metadata]
creation_date = "2026/07/10"
integration = ["gcp"]
maturity = "production"
min_stack_comments = "Requires ES|QL JSON_EXTRACT on _source to read gcp.audit.request.spec.request from flattened request bodies."
min_stack_version = "9.4.0"
updated_date = "2026/07/10"

[rule]
author = ["Elastic"]
description = """
Detects creation of a GKE CertificateSigningRequest (CSR) whose decoded subject requests a highly privileged
Kubernetes identity in the Common Name (CN), such as system:masters, system:kube-controller-manager, or system:admin.
This rule is scoped to identities with cluster-admin-equivalent or control-plane impersonation value. Attackers who can
create and approve CSRs can use this technique to clone credentials for powerful identities and obtain durable cluster
access. This signal applies to any actor, including compromised node identities that use legitimate kubelet signers
but request a privileged CN.
"""
false_positives = [
    """
    Legitimate GKE automation does not request certificates for system:masters, system:kube-controller-manager, or
    system:admin as the CSR subject. Node bootstrap and kubelet rotation use system:node:* identities instead. Alerts
    should be rare; tune exclusions only for documented custom PKI workflows that intentionally mint these identities.
    """,
]
from = "now-6m"
language = "esql"
license = "Elastic License v2"
name = "GKE Certificate Signing Request for Privileged Identity"
note = """## Triage and analysis

### Investigating GKE Certificate Signing Request for Privileged Identity

This rule uses `JSON_EXTRACT(_source, "$.gcp.audit.request.spec.request")` to read the outer base64 CSR from CSR
create events, double-decodes it to DER in `Esql.csr_der`, and matches privileged Common Names. It is scoped to
identities with cluster-admin-equivalent or control-plane impersonation value (`system:masters`, `system:kube-controller-manager`,
and `system:admin`). The alert includes `Esql.csr_pem` and `Esql.csr_der` so the requested identity is visible without
manual decoding.

To validate manually from the create event:

```bash
# Full decoded PEM block
echo "<gcp.audit.request.spec.request>" | base64 -d

# Parsed CSR details (subject, key type/size, extensions, signature)
echo "<gcp.audit.request.spec.request>" | base64 -d | openssl req -noout -text

# Subject only
echo "<gcp.audit.request.spec.request>" | base64 -d | openssl req -noout -subject
```

Matched privileged identities:

- `system:masters` (cluster-admin group)
- `system:kube-controller-manager`
- `system:admin`

### Possible investigation steps

- Identify `client.user.email`, `source.ip`, and whether the actor is expected to request certificates for these
  identities.
- Review `gcp.audit.request.spec.signerName` to determine which certificate authority would sign the request.
- Check for self-approval or controller approval on the same `gcp.audit.resource_name` within a short window.
- Correlate with secret reads, RBAC changes, or TokenRequest activity from the same actor.

### False positive analysis

- Known control-plane and kube-system identities do not legitimately create CSRs for these subjects in GKE; any match
  warrants review.

### Related rules

- GKE Certificate Signing Request API Client Signer Requested - 1e344fba-a2f7-462b-aaec-d6c8f80d5a28
- GKE Certificate Signing Request Self-Approved - e155e658-3dcd-4d27-a4e5-1d8da6704b0e
- GKE Client Certificate Signing Request Created or Approved - ec67ab57-945a-4edb-84f8-1d7a51f46544

### Response and remediation

- Deny or delete the CSR, revoke issued credentials if already signed, and tighten CSR create/approval RBAC.

"""
setup = "The GCP Fleet integration with GKE audit logs enabled is required. Request body capture for CSR create events (`gcp.audit.request.spec.request`) typically requires RequestResponse audit level on CertificateSigningRequest resources."
references = [
    "https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/",
    "https://kubernetes.io/docs/concepts/security/rbac-good-practices/",
    "https://raesene.github.io/blog/2022/12/21/Kubernetes-persistence-with-Tocan-and-Teisteanas/",
    "https://stratus-red-team.cloud/attack-techniques/kubernetes/k8s.persistence.create-client-certificate/",
    "https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/",
]
risk_score = 73
rule_id = "4159bec9-76ad-4cdc-a797-4a8572073bbe"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: GCP",
    "Data Source: GCP Audit Logs",
    "Data Source: Google Cloud Platform",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-gcp.audit-* metadata _id, _index, _version, _source
| where data_stream.dataset == "gcp.audit"
    and service.name == "k8s.io"
    and event.outcome == "success"
    and event.action == "io.k8s.certificates.v1.certificatesigningrequests.create"
| eval Esql.csr_request = json_extract(_source, "$.gcp.audit.request.spec.request")
| where Esql.csr_request is not null
| eval Esql.csr_pem = from_base64(Esql.csr_request)
| eval Esql.csr_body_b64 = replace(
    replace(
      replace(
        replace(Esql.csr_pem, "-----BEGIN CERTIFICATE REQUEST-----", ""),
        "-----END CERTIFICATE REQUEST-----", ""),
      "\r", ""),
    "\n", "")
| eval Esql.csr_der = from_base64(Esql.csr_body_b64)
| where Esql.csr_der like "*system:masters*"
    or Esql.csr_der like "*system:kube-controller-manager*"
    or Esql.csr_der like "*system:admin*"
| keep _id, _index, _version, @timestamp, client.user.email, gcp.audit.resource_name, source.ip, user_agent.original, Esql.*, event.*, gcp.audit.request, gcp.audit.response, data_stream.namespace
'''

[[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.006"
name = "Additional Container Cluster Roles"
reference = "https://attack.mitre.org/techniques/T1098/006/"

[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"

[[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.006"
name = "Additional Container Cluster Roles"
reference = "https://attack.mitre.org/techniques/T1098/006/"

[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "client.user.email",
    "source.ip",
    "user_agent.original",
    "event.action",
    "event.outcome",
    "gcp.audit.resource_name",
    "Esql.csr_request",
    "Esql.csr_pem",
    "Esql.csr_der",
    "data_stream.namespace",
]

[rule]
description = """
Identifies the execution of a recently downloaded file via launchctl submit. Adversaries may download payloads with curl
or wget and register them as transient launchd jobs in order to execute them in the background.
"""
id = "6b950b18-a6b4-465c-876b-e9536b282471"
license = "Elastic License v2"
name = "Launchctl Submit Execution of Downloaded File"
os_list = ["macos"]
version = "1.0.1"

query = '''
sequence with maxspan=1m
  [process where event.type == "start" and event.action == "exec" and 
   process.name in ("curl", "nscurl", "wget") and process.command_line like "*http*"] as event0
  [file where event.action != "deletion" and process.name in ("curl", "nscurl", "wget") and 
   process.entity_id == event0.process.entity_id] as event1
  [process where event.type == "start" and event.action == "exec" and
    process.name == "launchctl" and process.args == "submit" and process.args == "-l" and
    stringcontains~(process.command_line, event1.file.name)]
'''

min_endpoint_version = "8.16.0"
optional_actions = []
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 2

[[actions]]
action = "kill_process"
field = "process.parent.entity_id"
state = 2

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1569"
name = "System Services"
reference = "https://attack.mitre.org/techniques/T1569/"
[[threat.technique.subtechnique]]
id = "T1569.001"
name = "Launchctl"
reference = "https://attack.mitre.org/techniques/T1569/001/"



[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"

[internal]
min_endpoint_version = "8.16.0"

[rule]
description = """
Detects when a process is executed via an interactive shell. C2 platforms will commonly spawn an interactive shell
providing the threat actor with a remote shell on the system as if they were physically at the terminal allowing them to
send and execute commands manually.
"""
id = "aa02591f-c9e6-4317-841e-0b075b9515ff"
license = "Elastic License v2"
name = "Linux Suspicious Child Process Execution via Interactive Shell"
os_list = ["linux"]
version = "1.0.25"

query = '''
process where event.type == "start" and event.action == "exec" and process.args in ("-i", "-il", "-li") and process.args_count <= 2 and
process.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.parent.args_count > 1 and
process.parent.name like (
  "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "python*", "php*", "socat",
  "perl", "ruby", "lua*", "openssl", "nc", "ncat", "netcat", "netcat.openbsd",
  "netcat.traditional", "nc.openbsd", "nc.traditional", "telnet", "awk", "node"
) and not (
  process.parent.args like (
    "echo*| sudo -S su; sudo su;*SHELL -i", "/usr/share/kali-menu/exec-in-shell", "/usr/bin/kali-treecd", "pipenv",
    "/usr/scratch/xar/23e8559c/bin/python"
  ) or
  process.parent.command_line in (
    "/bin/sh -c bash -i </dev/tty >/dev/tty 2>/dev/tty", "/bin/bash --login --posix", "bash -c sudo su - oracle; $SHELL -i",
    "/bin/bash /opt/scripts/health-check.sh"
  ) or
  process.parent.command_line like (
    "/usr/scratch/*poetry shell", "*/u01/app/oracle.ahf/tfa/internal/tmp/*.sh*", "*/opt/oracle/oracle.ahf/tfa/internal/*.sh*",
    "bash -c ls -al; $SHELL -i", "bash -c cd ~/GIT/salt/pillars; $SHELL -i", "bash -c cd ~/GIT/ansible-infra; $SHELL -i",
    "bash -c cd ~/GIT/salt/states; $SHELL -i", "bash -c cd ~/GIT/puppet/hieradata; $SHELL -i",
    "bash -c cd ~/GIT/puppet/ind_legacy; $SHELL -i",
    """bash -c sudo -iu oracle bash -ic 'do_host P1 "hostname;/home/*/scripts/get_status;"'; $SHELL -i"""
  ) or
  process.command_line == "/opt/cursor.appimage -i" or
  process.parent.executable like (
    "/mnt/*/.vscode-server/bin/*/node", "/vscode/vscode-server/bin/*/node", "/home/*/.vscode-server/bin/*/node",
    "/usr/scratch/*/.vscode-server/bin/*/node", "/home/*/.vscode-server/*/server/node", "/scratch/user/*/.vscode-server/cli/servers/*/server/node",
    "/home/*/.vscode/cli/servers/*/server/node", "/root/.vscode-server/cli/servers/*/server/node", "/mnt/*/.vscode-server/cli/servers/*/server/node",
    "/home/*/.antigravity-server/bin/*/node", "/user/*/.trae-server/bin/*/node", "/var/lib/docker/overlay2/*/merged/vscode/vscode-server/bin/linux-x64/*/node",
    "/home/*/miniforge3/envs/*/bin/python*", "/home/*/.cursor-server/bin/linux-x64/*/node", "/home/*/.vscode-server-insiders/bin/*/node"
  ) or
  (process.parent.command_line like ("*pipenv*", "*poetry*") and process.parent.args:"shell") or
  (
    process.parent.command_line like "/bin/sh -c cat << 'EOF' | chroot /host*k8s-puppet-runner*" and
    process.executable in ("/usr/bin/bash", "/bin/bash")
  )
)
'''

min_endpoint_version = "7.15.0"
optional_actions = []
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0

[[actions]]
action = "kill_process"
field = "process.parent.entity_id"
state = 0

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[threat.technique.subtechnique]]
id = "T1059.004"
name = "Unix Shell"
reference = "https://attack.mitre.org/techniques/T1059/004/"



[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1071"
name = "Application Layer Protocol"
reference = "https://attack.mitre.org/techniques/T1071/"


[threat.tactic]
id = "TA0011"
name = "Command and Control"
reference = "https://attack.mitre.org/tactics/TA0011/"

[internal]
min_endpoint_version = "7.15.0"