Elastic rules: 30

[metadata]
creation_date = "2026/03/17"
integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel", "auditd_manager"]
maturity = "production"
updated_date = "2026/03/17"

[rule]
author = ["Elastic"]
description = """
Detects the execution of "apparmor_parser" using the "-o" option to write a compiled AppArmor
profile to an output file. This functionality is normally used by system administration tools
or package installation scripts when building or loading AppArmor policies. In adversarial
scenarios, attackers may use "apparmor_parser" to compile custom AppArmor profiles that can
later be loaded into the kernel through AppArmor policy management interfaces. Malicious
profiles may weaken security controls, alter the behavior of privileged programs, or assist in
exploitation chains involving AppArmor policy manipulation.
"""
from = "now-9m"
index = [
    "logs-endpoint.events.process*",
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-auditd_manager.auditd-*",
    "auditbeat-*",
]
language = "eql"
license = "Elastic License v2"
name = "AppArmor Profile Compilation via apparmor_parser"
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 AppArmor Profile Compilation via apparmor_parser

This alert flags a Linux process using apparmor_parser to write a compiled AppArmor policy to disk, an action administrators and package scripts use but adversaries can abuse to stage policy changes. An attacker with root access can compile a custom profile that grants a trojanized service broader file or capability access, then load it to weaken confinement and support privilege escalation or stealthy persistence.

### Possible investigation steps

- Review the full command line, parent and ancestor process chain, executing user, tty or session, and working directory to determine whether the activity came from expected package management or configuration tooling versus an interactive shell.
- Identify the source profile and output file paths, then inspect the profile for broad file access, dangerous capability grants, unconfined transitions, or complain/disable settings that would weaken confinement for sensitive binaries or services.
- Correlate nearby events for writes under AppArmor policy directories, subsequent policy loads or reloads, package installation actions, and restarts of the targeted application to confirm whether the compiled profile was actually deployed.
- Compare the activity against host and peer-system baselines and validate it with change records, deployment jobs, or package updates tied to the same account or system to quickly distinguish administrative maintenance from anomalous behavior.
- If the execution is not authorized, preserve the generated profile and related scripts, restore affected policy files from a known-good source, and review recent privileged activity on the host for additional persistence or defense-evasion changes.

### False positive analysis

- Operating system package installation or upgrade can invoke apparmor_parser with -o to precompile a vendor profile during a post-install action; verify this by reviewing the parent process and nearby package-management activity for an authorized update at the same time.
- A system administrator may compile a new or modified local AppArmor profile while hardening or troubleshooting a service; verify the executing user, source and output file paths, and whether the change aligns with approved maintenance or documented policy updates.

### Response and remediation

- Isolate the affected Linux host from the network and stop any service whose confinement was altered if the compiled profile was loaded or written into `/etc/apparmor.d/` or AppArmor cache directories, to prevent further policy abuse.
- Preserve the malicious source profile, compiled output, invoking script, and shell history for evidence, then delete unauthorized files from `/etc/apparmor.d/`, `/etc/apparmor.d/disable/`, and cache paths and unload the rogue policy with approved AppArmor administration commands.
- Remove attacker persistence by reviewing and cleaning systemd unit files, timers, cron entries, package maintainer scripts, login startup files, and sudoers changes that call `apparmor_parser` or restore the profile at boot.
- Reset or revoke credentials used on the host, including root and sudo-capable accounts, service account secrets, and unauthorized `authorized_keys`, if the attacker had interactive access or modified privileged services.
- Restore AppArmor policy files, affected binaries, and related service configurations from trusted packages, configuration management, or a gold image, then reload AppArmor in enforce mode and confirm the targeted program is confined by the expected profile.
- Escalate to incident response immediately if the custom profile targeted `sshd`, `sudo`, container runtimes, web-facing daemons, or appears on multiple hosts, and harden the environment by limiting write access to AppArmor policy paths, alerting on future `apparmor_parser -o` use outside approved package activity, and enforcing change control for policy updates.
"""
references = [
    "https://cdn2.qualys.com/advisory/2026/03/10/crack-armor.txt",
    "https://blog.qualys.com/vulnerabilities-threat-research/2026/03/12/crackarmor-critical-apparmor-flaws-enable-local-privilege-escalation-to-root",
]
risk_score = 21
rule_id = "d26331be-affe-46b2-bf4e-203d0e2d364c"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

### Elastic Defend Integration Setup
Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.

#### Prerequisite Requirements:
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Auditd Manager",
    "Data Source: Elastic Defend",
    "Data Source: Elastic Endgame",
    "Data Source: Crowdstrike",
    "Data Source: SentinelOne",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
process.name == "apparmor_parser" and process.args in ("--ofile*", "-o*", "--output*")
'''

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

[[rule.threat.technique]]
id = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"

[[rule.threat.technique.subtechnique]]
id = "T1562.001"
name = "Disable or Modify Tools"
reference = "https://attack.mitre.org/techniques/T1562/001/"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

[metadata]
creation_date = "2020/04/27"
integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
Syslog is a critical component in Linux environments, responsible for logging system events and activities. Adversaries
may attempt to disable the syslog service to disrupt event logging and evade detection by security controls.
"""
from = "now-9m"
index = [
    "auditbeat-*",
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Attempt to Disable Syslog Service"
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 Attempt to Disable Syslog Service

Syslog is a critical component in Linux environments, responsible for logging system events and activities. Adversaries may target syslog to disable logging, thereby evading detection and obscuring their malicious actions. The detection rule identifies attempts to stop or disable syslog services by monitoring specific process actions and arguments, flagging suspicious commands that could indicate an attempt to impair logging defenses.

### Possible investigation steps

- Review the process details to identify the user account associated with the command execution, focusing on the process.name and process.args fields to determine if the action was legitimate or suspicious.
- Check the system's recent login history and user activity to identify any unauthorized access attempts or anomalies around the time the syslog service was targeted.
- Investigate the parent process of the flagged command to understand the context of its execution and determine if it was initiated by a legitimate application or script.
- Examine other logs and alerts from the same host around the time of the event to identify any correlated suspicious activities or patterns that might indicate a broader attack.
- Assess the system for any signs of compromise, such as unexpected changes in configuration files, unauthorized software installations, or unusual network connections, to determine if the attempt to disable syslog is part of a larger attack.

### False positive analysis

- Routine maintenance activities may trigger this rule, such as scheduled service restarts or system updates. To manage this, create exceptions for known maintenance windows or specific administrative accounts performing these tasks.
- Automated scripts or configuration management tools like Ansible or Puppet might stop or disable syslog services as part of their operations. Identify these scripts and whitelist their execution paths or associated user accounts.
- Testing environments often simulate service disruptions, including syslog, for resilience testing. Exclude these environments from the rule or adjust the rule to ignore specific test-related processes.
- Some legitimate software installations or updates may require stopping syslog services temporarily. Monitor installation logs and exclude these processes if they are verified as non-threatening.
- In environments with multiple syslog implementations, ensure that the rule is not overly broad by refining the process arguments to match only the specific syslog services in use.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the adversary.
- Terminate any suspicious processes identified in the alert, specifically those attempting to stop or disable syslog services, to restore normal logging functionality.
- Restart the syslog service on the affected system to ensure that logging is re-enabled and operational, using commands like `systemctl start syslog` or `service syslog start`.
- Conduct a thorough review of recent logs, if available, to identify any additional suspicious activities or indicators of compromise that may have occurred prior to the syslog service being disabled.
- Escalate the incident to the security operations team for further investigation and to determine if the attack is part of a larger campaign or if other systems are affected.
- Implement additional monitoring on the affected system and similar systems to detect any further attempts to disable logging services, using enhanced logging and alerting mechanisms.
- Review and update access controls and permissions to ensure that only authorized personnel have the ability to modify or stop critical services like syslog, reducing the risk of future incidents."""
references = ["https://www.elastic.co/security-labs/detecting-log4j2-with-elastic-security"]
risk_score = 47
rule_id = "2f8a1226-5720-437d-9c20-e0029deb6194"
setup = """## Setup

This rule requires data coming in from one of the following integrations:
- Elastic Defend
- Auditbeat

### Elastic Defend Integration Setup
Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.

#### Prerequisite Requirements:
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).

### Auditbeat Setup
Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations.

#### The following steps should be executed in order to add the Auditbeat on a Linux System:
- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html).
- To run Auditbeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).
- To run Auditbeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html).
- For complete “Setup and Run Auditbeat” information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Crowdstrike",
    "Data Source: SentinelOne",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "start", "ProcessRollup2") and (
  (process.name == "service" and process.args == "stop") or
  (process.name == "chkconfig" and process.args == "off") or
  (process.name == "update-rc.d" and process.args in ("remove", "disable")) or
  (process.name == "systemctl" and process.args in ("disable", "stop", "kill", "mask"))
) and
process.args in ("syslog", "rsyslog", "syslog-ng", "syslog.service", "rsyslog.service", "syslog-ng.service") and
not (
  process.parent.name == "rsyslog-rotate" or
  process.args == "HUP"
)
'''

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

[[rule.threat.technique]]
id = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"

[[rule.threat.technique.subtechnique]]
id = "T1562.001"
name = "Disable or Modify Tools"
reference = "https://attack.mitre.org/techniques/T1562/001/"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

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

[[rule.threat.technique]]
id = "T1489"
name = "Service Stop"
reference = "https://attack.mitre.org/techniques/T1489/"

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

[metadata]
creation_date = "2021/01/13"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/03/18"

[rule]
author = ["Elastic"]
description = """
Adversaries may install a root certificate on a compromised system to avoid warnings when connecting to their command
and control servers. Root certificates are used in public key cryptography to identify a root certificate authority
(CA). When a root certificate is installed, the system or application will trust certificates in the root's chain of
trust that have been signed by the root certificate.
"""
false_positives = ["Certain applications may install root certificates for the purpose of inspecting SSL traffic."]
from = "now-9m"
index = ["logs-endpoint.events.*"]
language = "eql"
license = "Elastic License v2"
name = "Attempt to Install Root Certificate"
references = ["https://ss64.com/osx/security-cert.html"]
risk_score = 47
rule_id = "bc1eeacf-2972-434f-b782-3a532b100d67"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

### Elastic Defend Integration Setup
Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.

#### Prerequisite Requirements:
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).

#### The following steps should be executed in order to add the Elastic Defend integration on a macOS System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/current/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "macos" and event.type in ("start", "process_started") and
  process.name == "security" and process.args like "add-trusted-cert" and
  (process.parent.name like~ ("osascript", "bash", "sh", "zsh", "Terminal", "Python*") or (process.parent.code_signature.exists == false or process.parent.code_signature.trusted == false))
'''
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 Attempt to Install Root Certificate

Root certificates are pivotal in establishing trust within public key infrastructures, enabling secure communications by verifying the authenticity of digital certificates. Adversaries exploit this by installing unauthorized root certificates on compromised macOS systems, thereby bypassing security warnings and facilitating covert command and control communications. The detection rule identifies such activities by monitoring specific process executions related to certificate management, excluding known legitimate applications, thus highlighting potential malicious attempts to subvert trust controls.

### Possible investigation steps

- Review the process execution details to confirm the presence of the "security" process with the "add-trusted-cert" argument, as this indicates an attempt to add a root certificate.
- Check the parent process of the suspicious activity to ensure it is not one of the known legitimate applications, such as Bitdefender, as specified in the exclusion list.
- Investigate the user account associated with the process execution to determine if it is a legitimate user or potentially compromised.
- Examine recent system logs and network activity for any signs of unauthorized access or communication with known malicious command and control servers.
- Assess the system for any other indicators of compromise or unusual behavior that may suggest further malicious activity beyond the root certificate installation attempt.

### False positive analysis

- Security software installations or updates may trigger the rule as they often involve legitimate root certificate installations. Users can handle this by adding exceptions for known security software paths, such as Bitdefender, to prevent unnecessary alerts.
- System administrators performing routine maintenance or updates might install root certificates as part of their tasks. To mitigate this, create exceptions for processes executed by trusted admin accounts or during scheduled maintenance windows.
- Some enterprise applications may require the installation of root certificates for internal communications. Identify these applications and exclude their processes from the rule to avoid false positives.
- Development environments on macOS systems might involve testing with self-signed certificates, which could trigger the rule. Developers can be instructed to use designated test environments or have their processes excluded during development phases.

### Response and remediation

- Immediately isolate the affected macOS system from the network to prevent further unauthorized communications and potential data exfiltration.
- Revoke any unauthorized root certificates installed on the system by accessing the Keychain Access application and removing the suspicious certificates from the System Roots keychain.
- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized changes or suspicious activities that may have occurred alongside the root certificate installation.
- Restore the system to a known good state using backups or system snapshots taken prior to the compromise, ensuring that any malicious changes are reverted.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems in the network may be affected.
- Implement enhanced monitoring and alerting for similar activities by refining detection capabilities to include additional indicators of compromise (IOCs) related to unauthorized certificate installations.
- Review and update security policies and configurations to prevent unauthorized certificate installations, such as enforcing stricter access controls and requiring administrative approval for certificate management actions."""


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1553"
name = "Subvert Trust Controls"
reference = "https://attack.mitre.org/techniques/T1553/"
[[rule.threat.technique.subtechnique]]
id = "T1553.004"
name = "Install Root Certificate"
reference = "https://attack.mitre.org/techniques/T1553/004/"



[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

[metadata]
creation_date = "2026/06/05"
integration = ["aws"]
maturity = "production"
updated_date = "2026/06/05"

[rule]
author = ["Elastic"]
description = """
Detects control-plane mutations to AWS Bedrock knowledge bases and their backing RAG data sources via CloudTrail. An
adversary with access to Bedrock Agent APIs can poison the corpus that RAG-enabled models treat as authoritative by
ingesting attacker-controlled documents (IngestKnowledgeBaseDocuments, StartIngestionJob), deleting legitimate documents
(DeleteKnowledgeBaseDocuments), or repointing/altering the data source itself (CreateDataSource, UpdateDataSource,
DeleteDataSource, UpdateKnowledgeBase). Because downstream applications and users trust model answers grounded in this
stored data, tampering with the corpus is a stored data manipulation that can drive misinformation, fraud, or
manipulated decisions at inference time. This is a New Terms rule that looks for the first time a given identity ARN
performs one of these knowledge base or data source mutations within the history window.
"""
false_positives = [
    """
    Legitimate knowledge base maintenance, content onboarding, and scheduled re-ingestion performed by data engineering
    teams, MLOps automation, or infrastructure-as-code pipelines will generate these events. Validate the calling
    identity, user agent, and source IP against known automation and approved operators. If a known maintenance workflow
    is causing noise, it can be exempted from this rule.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Bedrock Knowledge Base or RAG Data Source Tampering"
note = """## Triage and analysis

### Investigating AWS Bedrock Knowledge Base or RAG Data Source Tampering

AWS Bedrock knowledge bases provide Retrieval-Augmented Generation (RAG) by grounding model responses in a stored
corpus that is synchronized from a configured data source. Because RAG-enabled applications present these grounded
answers as authoritative, an adversary who can ingest, delete, or repoint the underlying corpus can poison the answers
returned to downstream users and systems. This rule detects control-plane changes to knowledge bases and data sources
that could enable such corpus poisoning.

#### Possible investigation steps

- **Identify the actor and context**
  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and
    `aws.cloudtrail.user_identity.access_key_id`.
  - Examine `source.ip`, `user_agent.original`, and `aws.cloudtrail.user_identity.invoked_by` to determine whether the
    change came from an approved operator, automation, or an unexpected origin.
  - Confirm a related change request exists (content update, data source migration, scheduled ingestion).
- **Validate the specific action**
  - Inspect `event.action` and `aws.cloudtrail.flattened.request_parameters` to identify the knowledge base, data
    source, and any S3 bucket / ingestion configuration referenced.
  - For `CreateDataSource` / `UpdateDataSource`, verify the data source location (e.g., S3 bucket) is org-owned and not
    attacker-controlled.
  - For `IngestKnowledgeBaseDocuments` / `StartIngestionJob`, review what content was ingested and from where.
  - For `DeleteKnowledgeBaseDocuments` / `DeleteDataSource`, determine whether legitimate content was removed.
- **Correlate activity**
  - Look for prior enumeration of Bedrock resources or anomalous IAM/STS activity from the same identity.
  - Review `cloud.account.id` and `cloud.region` to confirm the change occurred where expected.

### False positive analysis

- **Planned content maintenance**: Routine ingestion, document updates, and re-syncs by data teams or MLOps automation
  are expected. Validate against change tickets and known automation roles.
- **Infrastructure-as-code**: Pipelines may create or update data sources during deployments. Confirm the source IP and
  ARN match expected automation.

### Response and remediation

- If unauthorized, suspend or disable the implicated knowledge base and data source to prevent further poisoned
  retrieval, and revert the corpus to a known-good state.
- Disable or rotate the credentials identified in `aws.cloudtrail.user_identity.access_key_id` if compromise is
  suspected.
- Audit recent ingestion jobs and document changes, and validate the integrity of the data source location.
- Restrict Bedrock Agent knowledge base and data source mutation permissions to a small set of trusted roles.
"""
references = [
    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_Operations_Agents_for_Amazon_Bedrock.html"
]
risk_score = 47
rule_id = "7811b5f7-9e07-4999-87aa-a950365cd327"
setup = """## Setup

This rule requires the AWS CloudTrail integration. The data source and knowledge base configuration actions are management 
events (captured by default), but the direct document operations (`IngestKnowledgeBaseDocuments`, `DeleteKnowledgeBaseDocuments`) 
are Bedrock CloudTrail **data events** that are off by default. Without Bedrock data-event logging enabled on the trail, this rule 
provides only **partial coverage** — it will see config changes but not direct document ingestion/deletion, the primary poisoning 
vector. Enable Bedrock data-event logging for full coverage.
"""

severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: LLM",
    "Data Source: AWS",
    "Data Source: AWS CloudTrail",
    "Data Source: Amazon Web Services",
    "Data Source: Amazon Bedrock",
    "Use Case: Threat Detection",
    "Resources: Investigation Guide",
    "Tactic: Impact",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "aws.cloudtrail" and
    event.provider: "bedrock.amazonaws.com" and
    event.action: (
        "IngestKnowledgeBaseDocuments" or
        "DeleteKnowledgeBaseDocuments" or
        "UpdateKnowledgeBase" or
        "CreateDataSource" or
        "UpdateDataSource" or
        "DeleteDataSource" or
        "StartIngestionJob" or
        "DeleteKnowledgeBase"
    ) and
    event.outcome: "success"
'''


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

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

[[rule.threat.technique.subtechnique]]
id = "T1565.001"
name = "Stored Data Manipulation"
reference = "https://attack.mitre.org/techniques/T1565/001/"

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

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

[rule.new_terms]
field = "new_terms_fields"
value = ["cloud.account.id"]

[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

[metadata]
creation_date = "2024/04/16"
integration = ["aws"]
maturity = "production"
updated_date = "2026/08/05"

[rule]
author = ["Elastic"]
description = """
Identifies an AWS Amazon Machine Image (AMI) being shared with another AWS account. Adversaries with access may share an AMI with an external AWS account as a means of data exfiltration. AMIs can contain secrets, bash histories, code artifacts, and other sensitive data that adversaries may abuse if shared with unauthorized accounts. AMIs can be made publicly available accidentally as well.
"""
false_positives = [
    """
    AMI sharing is a common practice in AWS environments. Ensure that the sharing is authorized before taking action.
    AWS Marketplace subscriptions automatically result in assets.marketplace.amazonaws.com invoking ModifyImageAttribute to share the AMI with your account. This rule excludes Marketplace-invoked sharing by design. Other AWS services like workspaces.amazonaws.com and backup.amazonaws.com may invoke this action when users configure sharing through WorkSpaces or Backup plans. Review such service-invoked events to confirm they match legitimate and intended sharing configurations.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
interval = "5m"
language = "kuery"
license = "Elastic License v2"
name = "AWS EC2 AMI Shared with Another Account"
note = """
## Triage and analysis

### Investigating AWS EC2 AMI Shared with Another Account

This rule identifies when an Amazon Machine Image (AMI) is shared with another AWS account. While sharing AMIs is a common practice, adversaries may exploit this feature to exfiltrate data by sharing AMIs with external accounts under their control.

#### Possible Investigation Steps

- **Review the Sharing Event**: Identify the AMI involved and review the event details in AWS CloudTrail. Look for `ModifyImageAttribute` actions where the AMI attributes were changed to include additional user accounts.
    - **Request and Response Parameters**: Check the `aws.cloudtrail.request_parameters` and `aws.response.response_elements` fields in the CloudTrail event to identify the AMI ID and the user ID of the account with which the AMI was shared.
- **Verify the Shared AMI**: Check the AMI that was shared and its contents to determine the sensitivity of the data stored within it.
- **Contextualize with Recent Changes**: Compare this sharing event against recent changes in AMI configurations and deployments. Look for any other recent permissions changes or unusual administrative actions.
- **Validate External Account**: Examine the AWS account to which the AMI was shared. Determine whether this account is known and previously authorized to access such resources.
- **Interview Relevant Personnel**: If the share was initiated by a user, verify the intent and authorization for this action with the person or team responsible for managing AMI deployments.
- **Audit Related Security Policies**: Check the security policies governing AMI sharing within your organization to ensure they are being followed and are adequate to prevent unauthorized sharing.

### False Positive Analysis

- **Legitimate Sharing Practices**: AMI sharing is a common and legitimate practice for collaboration and resource management in AWS. Always verify that the sharing activity was unauthorized before escalating.
- **Automation Tools**: Some organizations use automation tools for AMI management which might programmatically share AMIs. Verify if such tools are in operation and whether their actions are responsible for the observed behavior.
- **AWS Services**: Some AWS services, such as WorkSpaces and Backup, automate AMI sharing when users configure cross-account sharing or disaster recovery plans. These will appear in CloudTrail with `userIdentity.invokedBy` and `source.address` fields like `workspaces.amazonaws.com` or `backup.amazonaws.com`. Confirm that such activity aligns with your organization's approved configurations.

### Response and Remediation

- **Review and Revoke Unauthorized Shares**: If the share is found to be unauthorized, immediately revoke the shared permissions from the AMI.
- **Enhance Monitoring of Shared AMIs**: Implement monitoring to track changes to shared AMIs and alert on unauthorized access patterns.
- **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.
- **Policy Update**: Review and possibly update your organization’s policies on AMI sharing to tighten control and prevent unauthorized access.
- **Educate Users**: Conduct training sessions for users involved in managing AMIs to reinforce best practices and organizational policies regarding AMI sharing.

### Additional Information

For more information on managing and sharing AMIs, refer to the [Amazon EC2 User Guide on AMIs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) and [Sharing AMIs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html). Additionally, explore adversarial techniques related to data exfiltration via AMI sharing as documented by Stratus Red Team [here](https://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.ec2-share-ami/).

"""
references = [
    "https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html",
    "https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html",
    "https://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.ec2-share-ami/",
]
risk_score = 73
rule_id = "6a309864-fc3f-11ee-b8cc-f661ea17fbce"
severity = "high"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS EC2",
    "Tactic: Exfiltration",
    "Rule Type: Custom Query (KQL)",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail" and event.provider: "ec2.amazonaws.com"
    and event.action: ModifyImageAttribute and event.outcome: success
    and aws.cloudtrail.request_parameters: *add=*
    and not aws.cloudtrail.user_identity.invoked_by: "assets.marketplace.amazonaws.com"
    and not user_agent.original: (*packer-plugin-amazon* or *Ansible*)
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1537"
name = "Transfer Data to Cloud Account"
reference = "https://attack.mitre.org/techniques/T1537/"


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

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

[rule]
author = ["Elastic", "Austin Songer"]
description = """
Identifies AWS CloudTrail events where an EC2 route table or association has been modified or deleted. Route table or
association modifications can be used by attackers to disrupt network traffic, reroute communications, or maintain persistence in a compromised environment. This is a New Terms rule that detects the first instance of this behavior by a user or role.
"""
false_positives = [
    """
    Route Tables could be modified or deleted by a system administrator. Verify whether the user identity, user agent,
    and/or hostname should be making changes in your environment. Route Tables being modified from unfamiliar users
    should be investigated. If known behavior is causing false positives, it can be exempted from the rule. Also
    automated processes that use Terraform may lead to false positives.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS EC2 Route Table Modified or Deleted"
note = """
## Triage and Analysis

### Investigating AWS EC2 Route Table Modified or Deleted

This rule detects modifications or deletions of AWS route tables using actions such as `ReplaceRoute`, `ReplaceRouteTableAssociation`, `DeleteRouteTable`, `DeleteRoute`, or `DisassociateRouteTable`. These actions may indicate legitimate administrative activity, but they can also be abused by attackers to disrupt network traffic, reroute communications, or maintain persistence in a compromised environment.

#### Possible Investigation Steps

- **Review Request Parameters:**
   - Check the `aws.cloudtrail.request_parameters` field. The sub-fields may vary depending on the `event.action` (e.g., `routeTableId` for `DeleteRouteTable`, `destinationCidrBlock` for `ReplaceRoute`).
   - Validate the affected route table, routes, or associations based on the API call:
     - For `ReplaceRoute`: Look for changes in specific routes using `destinationCidrBlock`.
     - For `ReplaceRouteTableAssociation`: Review the new association details (e.g., subnet ID).
     - For `DeleteRouteTable`: Confirm the `routeTableId` of the deleted table.
     - For `DisassociateRouteTable`: Verify the disassociated resources.

- **Review User Context**:
  - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to determine the user or role initiating the action. Investigate whether this user is authorized to perform these operations.
  - **Access Key ID**: Check the `aws.cloudtrail.user_identity.access_key_id` field to identify if the access key used was expected or potentially compromised.
  - **Access Patterns**: Validate whether the user or role has a history of performing route table modifications and whether this aligns with their expected responsibilities.

- **Analyze Request Details**:
  - **Action Type**: Verify the specific API call in the `event.action` field (e.g., `ReplaceRoute`, `DeleteRouteTable`) to understand the nature of the modification.
  - **Source IP and Geolocation**: Examine the `source.ip` and `source.geo` fields to confirm whether the request originated from a trusted location. Suspicious geolocations or IPs may indicate adversarial activity.
  - **User Agent**: Review the `user_agent.original` field to determine the tool used for the request (e.g., AWS CLI, Terraform). Unusual or custom user agents may indicate malicious intent.

- **Correlate with Other Activity**:
  - **Concurrent API Calls**: Look for related API calls (e.g., `CreateRoute`, `AuthorizeSecurityGroupIngress`, or `ModifyInstanceAttribute`) from the same user or IP to detect broader attack patterns.
  - **IAM Changes**: Investigate whether any IAM policy updates or privilege escalation attempts preceded this activity.
  - **Unusual Volume of Changes**: Check if the user has performed multiple route table modifications or deletions in a short timeframe.

- **Validate the Intent**:
  - **Planned Changes**: Confirm with administrators whether the route table changes were part of a planned update or maintenance activity.
  - **Permissions and Justification**: Ensure that the user or role has the least privilege necessary for these actions and that there is a valid reason for modifying the route table.

### False Positive Analysis

- **Routine Administration**: Route table modifications are often part of routine administrative tasks, such as creating new routes, updating associations, or removing unused resources.
- **Automation Tools**: Automated workflows, such as those executed by Terraform or CloudFormation, may trigger these events. Verify whether the `user_agent.original` field or source IP matches known automation tools.
- **Maintenance or Scaling**: Confirm whether these actions align with maintenance activities or scaling events (e.g., adding or removing subnets).

### Response and Remediation

- **Revoke Unauthorized Permissions**: If unauthorized, remove permissions for related actions from the user or role. You can use the managed [AWSDenyAll](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html) policy.
- **Restore the Route Table**:
  - If critical networking was impacted, restore the route table or reapply previous configurations from backups or Terraform state files.
  - Verify connectivity to affected subnets or instances to ensure no disruptions to services.
- **Audit IAM Policies**:
  - Limit route table modification permissions to specific trusted users, roles, or automation accounts.
  - Implement conditions in IAM policies, such as source IP restrictions, to reduce the risk of unauthorized access.
- **Monitor and Alert**:
  - Set up additional alerts for unexpected route table modifications or deletions.
  - Use VPC flow logs and CloudTrail to monitor for related suspicious activity.
- **Secure Automation**: Ensure automation tools, such as Terraform or CloudFormation, are configured securely and that their credentials are stored in secure locations like AWS Secrets Manager.
"""
references = [
    "https://github.com/easttimor/aws-incident-response#network-routing",
    "https://docs.datadoghq.com/security_platform/default_rules/aws-ec2-route-table-modified/",
    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ReplaceRoute.html",
    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ReplaceRouteTableAssociation",
    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteRouteTable.html",
    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteRoute.html",
    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DisassociateRouteTable.html",
]
risk_score = 21
rule_id = "e7cd5982-17c8-4959-874c-633acde7d426"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS EC2",
    "Use Case: Network Security Monitoring",
    "Resources: Investigation Guide",
    "Tactic: Persistence",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "ec2.amazonaws.com"
    and event.action:(
        "ReplaceRoute" or
        "ReplaceRouteTableAssociation" or
        "DeleteRouteTable" or
        "DeleteRoute" or
        "DisassociateRouteTable"
    )
    and event.outcome: "success"
'''

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user_agent.original",
    "source.ip",
    "aws.cloudtrail.user_identity.arn",
    "aws.cloudtrail.user_identity.type",
    "aws.cloudtrail.user_identity.access_key_id",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
    "aws.cloudtrail.response_elements"
]

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

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

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

[[rule.threat.technique]]
id = "T1578"
name = "Modify Cloud Compute Infrastructure"
reference = "https://attack.mitre.org/techniques/T1578/"

[[rule.threat.technique.subtechnique]]
id = "T1578.005"
name = "Modify Cloud Compute Configurations"
reference = "https://attack.mitre.org/techniques/T1578/005/"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[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 = "2020/05/26"
integration = ["aws"]
maturity = "production"
updated_date = "2026/07/08"

[rule]
author = ["Elastic", "Austin Songer"]
description = """
Detects the deactivation of a Multi-Factor Authentication (MFA) device in AWS Identity and Access Management (IAM). MFA
provides critical protection against unauthorized access by requiring a second factor for authentication. Adversaries or
compromised administrators may deactivate MFA devices to weaken account protections, disable strong authentication, or
prepare for privilege escalation or persistence. This rule monitors successful DeactivateMFADevice API calls, which
represent the point at which MFA protection is actually removed.
"""
false_positives = [
    """
    MFA device deactivation may occur legitimately during device rotation, user offboarding, or troubleshooting. For
    example, AWS requires deactivation of an existing MFA device before adding a replacement. These actions are often
    performed by administrators following approved change-control processes. To reduce false positives, validate whether
    the deactivation aligns with a documented workflow, known device replacement, or expected maintenance window. If
    performed outside of expected operational hours, by an unexpected user, or from an unfamiliar source IP, this event
    should be investigated for potential credential compromise or unauthorized tampering.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS IAM Deactivation of MFA Device"
note = """## Triage and analysis

### Investigating AWS IAM Deactivation of MFA Device

This rule detects successful deactivation of a Virtual MFA device in AWS IAM. 
Deactivation removes MFA enforcement from an IAM user, significantly lowering account resilience against credential theft or unauthorized access. 
Since MFA devices must be deactivated before deletion, this represents the earliest and most critical opportunity to detect potential account compromise or persistence activity.

For more information about using MFA in AWS, access the [official documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html).

#### Possible investigation steps

- **Identify the actor and context**
  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who initiated the deactivation.
  - Check whether the actor typically manages MFA or has the IAM permissions to perform such actions.
  - Review `user_agent.original` to confirm if the operation was performed via the AWS Console, CLI, or SDK.

- **Review the source and location**
  - Investigate `source.ip` and `source.geo` fields for unusual origins or unrecognized locations.
  - Determine if this request originated from known automation infrastructure, internal IP ranges, or a personal endpoint.

- **Correlate with other related activity**
  - Look for preceding API calls such as `ListMFADevices`, `GetSessionToken`, or `ListUsers`, which may indicate reconnaissance or IAM enumeration.
  - Search for subsequent `DeleteVirtualMFADevice` calls to confirm whether the deactivated device was later deleted — a common follow-up action.
  - Check for any privilege changes, credential creations (`CreateAccessKey`, `AttachUserPolicy`), or unexpected login attempts following the deactivation.

- **Validate authorization**
  - Confirm with IAM or security administrators whether the action was part of an authorized device rotation or remediation.
  - If not documented or approved, escalate as a potential credential compromise or persistence attempt.

### False positive analysis

- **Legitimate device rotation**
  - When replacing an MFA device, AWS requires deactivation of the existing device before the new one can be enabled.
- **Administrative maintenance**
  - IAM administrators or automation pipelines may deactivate MFA as part of account management or recovery workflows.

### Response and remediation

- **Containment**
  - Re-enable MFA for the affected IAM user (`EnableMFADevice`) or temporarily disable their login access until legitimacy is confirmed.
  - Revoke temporary credentials or tokens associated with the actor to prevent further misuse.

- **Investigation and scoping**
  - Review CloudTrail history for additional IAM configuration changes or access key creation events tied to the same principal.
  - Determine whether sensitive resources were accessed after MFA removal.
  - Identify whether multiple users had MFA devices deactivated in a short timeframe — an indicator of broader compromise.

- **Recovery and hardening**
  - Require MFA for all privileged IAM users and enforce it using service control policies (SCPs).
  - Enable GuardDuty or Security Hub findings for IAM anomaly detection related to account takeover or 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)** 
- **[DeactivateMFADevice API Reference](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html)**  
- **[Managing MFA Devices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html)** 
"""
references = [
    "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/deactivate-mfa-device.html",
    "https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html",
]
risk_score = 73
rule_id = "d8fc1cca-93ed-43c1-bbb6-c0dd3eff2958"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS CloudTrail",
    "Data Source: AWS IAM",
    "Resources: Investigation Guide",
    "Tactic: Impact",
    "Tactic: Persistence",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: aws.cloudtrail 
    and event.provider: iam.amazonaws.com 
    and event.action: DeactivateMFADevice 
    and event.outcome: success
'''


[[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/"

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

[[rule.threat.technique]]
id = "T1556"
name = "Modify Authentication Process"
reference = "https://attack.mitre.org/techniques/T1556/"

[[rule.threat.technique.subtechnique]]
id = "T1556.006"
name = "Multi-Factor Authentication"
reference = "https://attack.mitre.org/techniques/T1556/006/"

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

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

[[rule.threat.technique]]
id = "T1556"
name = "Modify Authentication Process"
reference = "https://attack.mitre.org/techniques/T1556/"

[[rule.threat.technique.subtechnique]]
id = "T1556.006"
name = "Multi-Factor Authentication"
reference = "https://attack.mitre.org/techniques/T1556/006/"

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

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

[rule]
author = ["Austin Songer"]
description = """
Identifies when the Azure role-based access control (Azure RBAC) permissions are modified for an Azure Blob. An
adversary may modify the permissions on a blob to weaken their target's security controls or an administrator may
inadvertently modify the permissions, which could lead to data exposure or loss.
"""
false_positives = [
    """
    Blob permissions may be modified by system administrators. Verify that the configuration change was expected.
    Exceptions can be added to this rule to filter expected behavior.
    """,
]
from = "now-9m"
index = ["logs-azure.activitylogs-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure Blob Storage Permissions Modified"
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 Azure Blob Storage Permissions Modified

Azure Blob Storage is a service for storing large amounts of unstructured data. It uses Azure RBAC to manage access, ensuring only authorized users can modify or access data. Adversaries may exploit this by altering permissions to gain unauthorized access or disrupt operations. The detection rule monitors specific Azure activity logs for successful permission changes, alerting analysts to potential security breaches or misconfigurations.

### Possible investigation steps

- Review the Azure activity logs to identify the user or service principal associated with the permission modification event by examining the relevant fields such as `event.dataset` and `azure.activitylogs.operation_name`.
- Check the `event.outcome` field to confirm the success of the permission modification and gather details on the specific permissions that were altered.
- Investigate the context of the modification by reviewing recent activities of the identified user or service principal to determine if the change aligns with their typical behavior or role.
- Assess the potential impact of the permission change on the affected Azure Blob by evaluating the sensitivity of the data and the new access levels granted.
- Cross-reference the modification event with any recent security alerts or incidents to identify if this change is part of a broader attack pattern or misconfiguration issue.
- Consult with the relevant data owners or administrators to verify if the permission change was authorized and necessary, and if not, take corrective actions to revert the changes.

### False positive analysis

- Routine administrative changes to Azure Blob permissions by authorized personnel can trigger alerts. To manage this, create exceptions for specific user accounts or roles that frequently perform legitimate permission modifications.
- Automated scripts or tools used for regular maintenance or deployment might modify permissions as part of their operation. Identify these scripts and exclude their activity from triggering alerts by using specific identifiers or tags associated with the scripts.
- Scheduled updates or policy changes that involve permission modifications can result in false positives. Document these schedules and adjust the monitoring rules to account for these timeframes, reducing unnecessary alerts.
- Integration with third-party services that require permission changes might cause alerts. Review and whitelist these services if they are verified and necessary for operations, ensuring they do not trigger false positives.

### Response and remediation

- Immediately revoke any unauthorized permissions identified in the Azure Blob Storage to prevent further unauthorized access or data exposure.
- Conduct a thorough review of the Azure Activity Logs to identify any other suspicious activities or permission changes that may have occurred around the same time.
- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized changes and any potential data exposure.
- Implement additional monitoring on the affected Azure Blob Storage accounts to detect any further unauthorized access attempts or permission modifications.
- Escalate the incident to the incident response team if there is evidence of a broader security breach or if sensitive data has been compromised.
- Review and update Azure RBAC policies to ensure that only necessary permissions are granted, and consider implementing more granular access controls to minimize the risk of future unauthorized modifications.
- Conduct a post-incident analysis to identify the root cause of the permission change and implement measures to prevent similar incidents in the future, such as enhancing logging and alerting capabilities.

## 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/role-based-access-control/built-in-roles"]
risk_score = 47
rule_id = "d79c4b2a-6134-4edd-86e6-564a92a933f9"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: Azure",
    "Use Case: Identity and Access Audit",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide"
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:(
     "MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/CONTAINERS/BLOBS/MANAGEOWNERSHIP/ACTION" or
     "MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/CONTAINERS/BLOBS/MODIFYPERMISSIONS/ACTION") and
  event.outcome:(Success or success)
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1222"
name = "File and Directory Permissions Modification"
reference = "https://attack.mitre.org/techniques/T1222/"


[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

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

[rule]
author = ["Elastic"]
description = """
Identifies when an Event Hub Authorization Rule is created or updated in Azure. An authorization rule is associated with
specific rights, and carries a pair of cryptographic keys. When you create an Event Hubs namespace, a policy rule named
RootManageSharedAccessKey is created for the namespace. This has manage permissions for the entire namespace and it's
recommended that you treat this rule like an administrative root account and don't use it in your application.
"""
false_positives = [
    """
    Authorization rule additions or modifications may be done by a system or network administrator. Verify whether the
    username, hostname, and/or resource name should be making changes in your environment. Authorization rule additions
    or modifications from unfamiliar users or hosts should be investigated. If known behavior is causing false
    positives, it can be exempted from the rule.
    """,
]
from = "now-9m"
index = ["logs-azure.activitylogs-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure Event Hub Authorization Rule Created or Updated"
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 Azure Event Hub Authorization Rule Created or Updated

Azure Event Hub Authorization Rules manage access to Event Hubs via cryptographic keys, akin to administrative credentials. Adversaries may exploit these rules to gain unauthorized access or escalate privileges, potentially exfiltrating data. The detection rule monitors for the creation or modification of these rules, flagging successful operations to identify potential misuse or unauthorized changes.

### Possible investigation steps

- Review the Azure activity logs to identify the user or service principal associated with the operation by examining the `azure.activitylogs.operation_name` and `event.outcome` fields.
- Check the timestamp of the event to determine when the authorization rule was created or updated, and correlate this with any other suspicious activities around the same time.
- Investigate the specific Event Hub namespace affected by the rule change to understand its role and importance within the organization.
- Verify if the `RootManageSharedAccessKey` or any other high-privilege authorization rule was involved, as these carry significant risk if misused.
- Assess the necessity and legitimacy of the rule change by contacting the user or team responsible for the Event Hub namespace to confirm if the change was authorized and aligns with operational needs.
- Examine any subsequent access patterns or data transfers from the affected Event Hub to detect potential data exfiltration or misuse following the rule change.

### False positive analysis

- Routine administrative updates to authorization rules by IT staff can trigger alerts. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
- Automated scripts or deployment tools that update authorization rules as part of regular operations may cause false positives. Identify these scripts and exclude their activity from alerts by filtering based on their service principal or user identity.
- Changes made by trusted third-party services integrated with Azure Event Hub might be flagged. Verify these services and exclude their operations by adding them to an allowlist.
- Frequent updates during development or testing phases can lead to false positives. Consider setting up separate monitoring profiles for development environments to reduce noise.
- Legitimate changes made by users with appropriate permissions might be misinterpreted as threats. Regularly review and update the list of authorized users to ensure only necessary personnel have access, and exclude their actions from alerts.

### Response and remediation

- Immediately revoke or rotate the cryptographic keys associated with the affected Event Hub Authorization Rule to prevent unauthorized access.
- Review the Azure Activity Logs to identify any unauthorized access or data exfiltration attempts that may have occurred using the compromised authorization rule.
- Implement conditional access policies to restrict access to Event Hub Authorization Rules based on user roles and network locations.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised.
- Conduct a security review of all Event Hub Authorization Rules to ensure that only necessary permissions are granted and that the RootManageSharedAccessKey is not used in applications.
- Enhance monitoring and alerting for changes to authorization rules by integrating with a Security Information and Event Management (SIEM) system to detect similar threats in the future.

## 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/event-hubs/authorize-access-shared-access-signature"]
risk_score = 47
rule_id = "b6dce542-2b75-4ffb-b7d6-38787298ba9d"
severity = "medium"
tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Log Auditing", "Tactic: Persistence", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.EVENTHUB/NAMESPACES/AUTHORIZATIONRULES/WRITE" 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 = "T1552"
name = "Unsecured Credentials"
reference = "https://attack.mitre.org/techniques/T1552/"

[[rule.threat.technique.subtechnique]]
id = "T1552.005"
name = "Cloud Instance Metadata API"
reference = "https://attack.mitre.org/techniques/T1552/005/"

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

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

[rule]
author = ["Elastic"]
description = """
Identifies modifications to a Key Vault in Azure. The Key Vault is a service that safeguards encryption keys and secrets
like certificates, connection strings, and passwords. Because this data is sensitive and business critical, access to
key vaults should be secured to allow only authorized applications and users. This is a New Terms rule that detects when this activity hasn't been seen by the user in a specified time frame.
"""
false_positives = [
    """
    Key vault modifications may be done by a system or network administrator. Verify whether the username, hostname,
    and/or resource name should be making changes in your environment. Key vault modifications from unfamiliar users or
    hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
    """,
]
from = "now-9m"
index = ["filebeat-*", "logs-azure.activitylogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure Key Vault Modified"
note = """## Triage and analysis

### Investigating Azure Key Vault Modified

Azure Key Vault is a cloud service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. It is crucial for managing sensitive data in Azure environments. Unauthorized modifications to Key Vaults can lead to data breaches or service disruptions. This rule detects modifications to Key Vaults, which may indicate potential security incidents or misconfigurations.

### Possible investigation steps
- Review the `azure.activitylogs.operation_name` field to identify the specific operation performed on the Key Vault. Common operations include `Microsoft.KeyVault/vaults/write` for modifications and `Microsoft.KeyVault/vaults/delete` for deletions.
- Check the `event.outcome` field to confirm the success of the operation. A successful outcome indicates that the modification or deletion was completed.
- Investigate the `azure.activitylogs.identity.principal_id` or `azure.activitylogs.identity.principal_name` fields to determine the user or service principal that performed the operation. This can help identify whether the action was authorized or potentially malicious.
- Analyze the `azure.activitylogs.resource_id` field to identify the specific Key Vault that was modified. This can help assess the impact of the change and whether it affects critical resources or applications.
- Cross-reference the time of the modification with other security events or alerts in the environment to identify any patterns or related activities that may indicate a coordinated attack or misconfiguration.
- Consult with relevant stakeholders or system owners to verify if the modification was planned or expected, and gather additional context if necessary.

### False positive analysis
- Routine maintenance activities by administrators can trigger alerts when they modify or delete Key Vaults. To manage this, create exceptions for known maintenance windows or specific administrator accounts.
- Automated scripts or tools used for Key Vault management might perform frequent updates or deletions, leading to false positives. Identify these scripts and exclude their operations from triggering alerts by using specific identifiers or tags.
- Changes made by authorized third-party services or integrations that manage Key Vault configurations can also result in false positives. Review and whitelist these services to prevent unnecessary alerts.
- Regular updates or deployments in a development or testing environment may cause alerts. Consider excluding these environments from monitoring or adjusting the rule to focus on production environments only.
- Temporary changes for troubleshooting or testing purposes might be flagged. Document these activities and use temporary exceptions to avoid false positives during these periods.

### Response and remediation
- Immediately isolate the affected Key Vault to prevent further unauthorized access or changes.
- Review the Azure activity logs to identify the specific operations performed on the Key Vault and their outcomes.
- Collaborate with security teams to assess the impact of the modifications and determine if any sensitive data was compromised.
- If unauthorized changes are confirmed, initiate incident response procedures, including notifying affected parties and conducting a thorough investigation.
- Implement additional monitoring and alerting for the affected Key Vault to detect any further suspicious activity.
"""
references = [
    "https://docs.microsoft.com/en-us/azure/key-vault/general/basic-concepts",
    "https://docs.microsoft.com/en-us/azure/key-vault/general/secure-your-key-vault",
    "https://learn.microsoft.com/en-us/azure/key-vault/general/security-features"
]
risk_score = 21
rule_id = "792dd7a6-7e00-4a0a-8a9a-a7c24720b5ec"
severity = "low"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Azure Activity Logs",
    "Tactic: Impact",
    "Use Case: Configuration Audit",
    "Resources: Investigation Guide"
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "azure.activitylogs"
    and azure.activitylogs.operation_name: MICROSOFT.KEYVAULT/VAULTS/*
    and event.outcome:(Success or success)
'''


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

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

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

[[rule.threat.technique]]
id = "T1578"
name = "Modify Cloud Compute Infrastructure"
reference = "https://attack.mitre.org/techniques/T1578/"

[[rule.threat.technique.subtechnique]]
id = "T1578.005"
name = "Modify Cloud Compute Configurations"
reference = "https://attack.mitre.org/techniques/T1578/005/"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[rule.new_terms]
field = "new_terms_fields"
value = ["azure.activitylogs.identity.claims_initiated_by_user.name"]

[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-14d"

[metadata]
creation_date = "2026/06/16"
integration = ["azure"]
maturity = "production"
updated_date = "2026/06/16"

[rule]
author = ["Elastic"]
description = """
Identifies the creation or update of a managed Azure Run Command resource
("MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMANDS/WRITE" or the virtual machine scale set equivalent) by an identity that
has not performed this operation recently. Unlike the action-based Run Command ("runCommand/action"), the managed Run
Command is a persistent resource on the VM whose creation or update executes the supplied script as System (Windows) or
root (Linux). Because creating a managed run command both executes code and leaves a durable object, adversaries can use
it as an alternative to the action invocation to evade detections that only watch "runCommand/action". Alerting on the
first time a given principal performs this operation surfaces unusual or unauthorized use while suppressing routine
automation that repeatedly manages the same run commands.
"""
false_positives = [
    """
    Infrastructure-as-code, configuration management, and patching automation may create or update managed run commands.
    The first occurrence per principal will alert; baseline expected service principals, managed identities, and admin
    users and exclude them if the activity is verified as authorized.
    """,
]
from = "now-9m"
index = ["logs-azure.activitylogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure VM Managed Run Command Created or Updated with Unusual Principal"
note = """## Triage and analysis

### Investigating Azure VM Managed Run Command Created or Updated with Unusual Principal

The managed Run Command (`runCommands/write`) creates or updates a persistent run command resource on a VM or VM scale
set. Creating the resource executes the supplied script as SYSTEM (Windows) or root (Linux). This rule uses a new terms
approach keyed on the acting principal, so it fires the first time a given identity performs this operation within the
history window.

### Triage checklist

- Identify the acting principal via `azure.activitylogs.identity.authorization.evidence.principal_id` and
  `azure.activitylogs.identity.authorization.evidence.principal_type` (User vs ServicePrincipal). Service principal or
  managed identity activity is more suspicious than a known admin user.
- Is the source IP/ASN consistent with corporate infrastructure or a known VPN?
- Inspect `azure.resource.id` for the target VM/VMSS and the run command resource name. Attacker-created names are often
  random or descriptive of intent.
- Did the same principal recently perform reconnaissance, role assignments, or other VM operations
  (`runCommand/action`, `extensions/write`, serial console connect)?
- Correlate with endpoint telemetry on the target host: process activity parented by the Azure guest agent
  (`WaAppAgent.exe` / `walinuxagent`) within ~120 seconds of the write timestamp.

### Possible investigation steps

- Review the principal's Entra ID sign-in logs and RBAC role assignments on the subscription, resource group, and VM.
- Retrieve the run command script content from the VM (the activity log does not contain the script body) to assess
  intent.
- Pivot on the VM for credential access, new local accounts, or outbound C2 connections following execution.

### Response and remediation

- If unauthorized, delete the managed run command resource, isolate the VM, rotate credentials reachable from it, and
  review RBAC on the affected scope.
- Collect endpoint and activity log artifacts per incident procedures.
"""
references = [
    "https://www.netspi.com/blog/technical-blog/adversary-simulation/7-ways-to-execute-command-on-azure-virtual-machine-virtual-machine-scale-sets/",
    "https://learn.microsoft.com/en-us/azure/virtual-machines/windows/run-command-managed",
    "https://hackingthe.cloud/azure/run-command-abuse/",
    "https://blog.pwnedlabs.io/diving-deep-into-azure-vm-attack-vectors",
    "https://www.sysdig.com/blog/the-expendable-extension-name-azure-vmaccess-naming-chaos-password-resets-and-a-detection-gap",
]
risk_score = 47
rule_id = "b4a80990-e028-4792-83eb-09e59959059f"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Endpoint",
    "Data Source: Azure",
    "Data Source: Azure Activity Logs",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"
query = '''
data_stream.dataset:azure.activitylogs and
    event.action:(
        "MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMANDS/WRITE" or
        "MICROSOFT.COMPUTE/VIRTUALMACHINESCALESETS/VIRTUALMACHINES/RUNCOMMANDS/WRITE"
    ) and event.outcome:(success or Success) and
    azure.activitylogs.identity.authorization.evidence.principal_id: *
'''

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "event.outcome",
    "azure.activitylogs.operation_name",
    "azure.activitylogs.identity.authorization.evidence.principal_id",
    "azure.activitylogs.identity.authorization.evidence.principal_type",
    "azure.activitylogs.identity.claims.appid",
    "azure.activitylogs.identity.claims_initiated_by_user.name",
    "azure.resource.id",
    "azure.resource.name",
    "source.ip",
    "source.geo.country_name",
    "source.as.organization.name",
    "azure.subscription_id",
    "azure.activitylogs.tenant_id",
]

[rule.new_terms]
field = "new_terms_fields"
value = ["azure.activitylogs.identity.authorization.evidence.principal_id"]

[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

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

[[rule.threat.technique]]
id = "T1651"
name = "Cloud Administration Command"
reference = "https://attack.mitre.org/techniques/T1651/"

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

[rule]
description = """
Detects when Node accesses crypto wallet or web browser files on a macOS system like crypto wallet files, or web browser
cookies. Malware like "BeaverTail", "InvisibleFerret", or "OtterCookie" all use malicious Node applications that
implement stealer functionality capable of grabbing sensitive files and exfiltrating them from a victim system.
"""
id = "555ec79a-b570-455e-aac9-d2df587d70bf"
license = "Elastic License v2"
name = "Crypto Wallet or Web Browser File Access via Nodejs"
os_list = ["macos"]
version = "1.0.4"

query = '''
file where event.action == "open" and (process.name == "node" or Effective_process.name == "node") and 
 (file.path like~ ("/Users/*/.electrum/*",
                   "/Users/*/Library/Application_Support/*/Default/Extensions/*",
                   "/Users/*/Library/Application Support/*/Default/Local Extension Settings/*",
                   "/Users/*/Library/Application Support/Electrum/*",
                   "/Users/*/Library/Application Support/Exodus/*", 
                   "/Users/*/Library/Application Support/Coinomi/*",
                   "/Users/*/Library/Application Support/Atomic/*",
                   "/Users/*/Library/Application Support/@trezor/*",
                   "/Users/*/Library/Application Support/Ledger Live/*",
                   "/Users/*/Library/Application Support/WasabiWallet/*",
                   "/Users/*/Monero/*",
                   "/Users/*/Library/Application Support/Bitcoin/*",
                   "/Users/*/Library/Application Support/Litecoin/*",
                   "/Users/*/Library/Application Support/DashCore/*",
                   "/Users/*/Library/Application Support/ElectronCash/*",
                   "/Users/*/Library/Application Support/Guarda/*",
                   "/Users/*/Library/Application Support/Dogecoin/*",
                   "/Users/*/Library/Application Support/BraveSoftware/Brave-Browser/BraveWallet/*",
                   "/Users/*/Library/Application Support/BraveSoftware/Brave-Browser/Default/Local Extension Settings/pgojbichloddijphfmfhhfolimnhjklk/*",
                   "/Users/*/Library/Application Support/Firefox/Profiles/*/extensions/*") or
   file.name like~ ("cookies.sqlite", 
                    "key?.db", 
                    "logins.json", 
                    "Cookies", 
                    "Cookies.binarycookies", 
                    "Login Data"))
'''

min_endpoint_version = "8.11.1"
optional_actions = []
[[actions]]
action = "kill_process"
field = "Effective_process.entity_id"
state = 0

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1552"
name = "Unsecured Credentials"
reference = "https://attack.mitre.org/techniques/T1552/"
[[threat.technique.subtechnique]]
id = "T1552.001"
name = "Credentials In Files"
reference = "https://attack.mitre.org/techniques/T1552/001/"



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

[internal]
min_endpoint_version = "8.11.1"

[rule]
description = """
Detects when curl or nscurl is executed followed by osascript execution within 15 seconds from the same parent process.
This pattern indicates potential malicious workflows where curl output is being piped to osascript for AppleScript
execution, commonly used for payload downloads and immediate execution or C2 communication.
"""
id = "d8a84851-53ac-42ba-8c41-dd16fda7e9da"
license = "Elastic License v2"
name = "Curl Output Piped to Osascript"
os_list = ["macos"]
version = "1.0.4"

query = '''
sequence by process.parent.entity_id with maxspan=20s
[process where event.type == "start" and event.action == "exec" and
  process.name in ("curl", "nscurl") and process.parent.name in ("bash", "sh", "zsh")]
[process where event.type == "start" and event.action == "exec" and 
  ((process.args == "osascript" and process.args == "-l" and process.args == "JavaScript" and process.args_count == 3) or 
   (process.args == "osascript" and process.args_count == 1))]
'''

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

[[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.002"
name = "AppleScript"
reference = "https://attack.mitre.org/techniques/T1059/002/"



[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1105"
name = "Ingress Tool Transfer"
reference = "https://attack.mitre.org/techniques/T1105/"


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

[internal]
min_endpoint_version = "8.16.0"

[metadata]
creation_date = "2023/07/14"
integration = ["windows"]
maturity = "production"
updated_date = "2026/02/09"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Identifies the use of Cmdlets and methods related to Microsoft Exchange Transport Agents install. Adversaries may
leverage malicious Microsoft Exchange Transport Agents to execute tasks in response to adversary-defined criteria,
establishing persistence.
"""
from = "now-119m"
index = ["winlogbeat-*", "logs-windows.powershell*"]
interval = "60m"
language = "kuery"
license = "Elastic License v2"
name = "Deprecated - Microsoft Exchange Transport Agent Install Script"
risk_score = 21
rule_id = "846fe13f-6772-4c83-bd39-9d16d4ad1a81"
setup = """## Setup

PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).
Setup instructions: https://ela.st/powershell-logging-setup
"""
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Data Source: PowerShell Logs",
    "Rule Type: BBR",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.category: "process" and host.os.type:windows and
  powershell.file.script_block_text : (
    (
    "Install-TransportAgent" or
    "Enable-TransportAgent"
    )
  ) and
  not user.id : "S-1-5-18" and
  not powershell.file.script_block_text : (
    "'Install-TransportAgent', 'Invoke-MonitoringProbe', 'Mount-Database', 'Move-ActiveMailboxDatabase'," or
    "'Enable-TransportAgent', 'Enable-TransportRule', 'Export-ActiveSyncLog', 'Export-AutoDiscoverConfig'," or
    ("scriptCmd.GetSteppablePipeline" and "ForwardHelpTargetName Install-TransportAgent")
  )
'''


[[rule.filters]]

[rule.filters.meta]
negate = true
[rule.filters.query.wildcard."file.path"]
case_insensitive = true
value = "?:\\\\Users\\\\*\\\\AppData\\\\Roaming\\\\Microsoft\\\\Exchange\\\\RemotePowerShell\\\\*"
[[rule.filters]]

[rule.filters.meta]
negate = true
[rule.filters.query.wildcard."file.path"]
case_insensitive = true
value = "?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Temp\\\\tmp_????????.???\\\\tmp_????????.???.ps?1"
[[rule.filters]]

[rule.filters.meta]
negate = true
[rule.filters.query.wildcard."file.path"]
case_insensitive = true
value = "?:\\\\Windows\\\\TEMP\\\\tmp_????????.???\\\\tmp_????????.???.ps?1"
[[rule.filters]]

[rule.filters.meta]
negate = true
[rule.filters.query.wildcard."file.path"]
case_insensitive = true
value = "?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Temp\\\\*\\\\tmp_????????.???\\\\tmp_????????.???.ps?1"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1505"
name = "Server Software Component"
reference = "https://attack.mitre.org/techniques/T1505/"
[[rule.threat.technique.subtechnique]]
id = "T1505.002"
name = "Transport Agent"
reference = "https://attack.mitre.org/techniques/T1505/002/"



[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[rule.threat.technique.subtechnique]]
id = "T1059.001"
name = "PowerShell"
reference = "https://attack.mitre.org/techniques/T1059/001/"



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

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

[rule]
author = ["Elastic"]
description = """
Identifies when a user is added as an owner for an Azure service principal. The service principal object defines what
the application can do in the specific tenant, who can access the application, and what resources the app can access. A
service principal object is created when an application is given permission to access resources in a tenant. An
adversary may add a user account as an owner for a service principal and use that account in order to define what an
application can do in the Azure AD tenant.
"""
from = "now-9m"
index = ["logs-azure.auditlogs-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID User Added as Service Principal Owner"
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 Entra ID User Added as Service Principal Owner

Azure service principals are crucial for managing application permissions within a tenant, defining access and capabilities. Adversaries may exploit this by adding themselves as owners, gaining control over application permissions and access. The detection rule monitors audit logs for successful owner additions, flagging potential unauthorized changes to maintain security integrity.

### Possible investigation steps

- Review the audit log entry to confirm the event dataset is 'azure.auditlogs' and the operation name is "Add owner to service principal" with a successful outcome.
- Identify the user account that was added as an owner and gather information about this account, including recent activity and any associated alerts.
- Determine the service principal involved by reviewing its details, such as the application it is associated with and the permissions it holds.
- Check the history of changes to the service principal to identify any other recent modifications or suspicious activities.
- Investigate the context and necessity of the ownership change by contacting the user or team responsible for the service principal to verify if the change was authorized.
- Assess the potential impact of the ownership change on the tenant's security posture, considering the permissions and access granted to the service principal.

### False positive analysis

- Routine administrative changes may trigger alerts when legitimate IT staff add themselves or others as owners for maintenance purposes. To manage this, create exceptions for known administrative accounts that frequently perform these actions.
- Automated processes or scripts that manage service principal ownership as part of regular operations can cause false positives. Identify and document these processes, then exclude them from triggering alerts by using specific identifiers or tags.
- Organizational changes, such as team restructuring, might lead to multiple legitimate ownership changes. During these periods, temporarily adjust the rule sensitivity or create temporary exceptions for specific user groups involved in the transition.
- Third-party applications that require ownership changes for integration purposes can also trigger alerts. Verify these applications and whitelist their associated service principal changes to prevent unnecessary alerts.

### Response and remediation

- Immediately revoke the added user's ownership from the Azure service principal to prevent unauthorized access and control.
- Conduct a thorough review of the affected service principal's permissions and access logs to identify any unauthorized changes or access attempts.
- Reset credentials and update any secrets or keys associated with the compromised service principal to mitigate potential misuse.
- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
- Implement conditional access policies to restrict who can add owners to service principals, ensuring only authorized personnel have this capability.
- Enhance monitoring and alerting for similar activities by increasing the sensitivity of alerts related to changes in service principal ownership.
- Document the incident and response actions taken to improve future incident response and refine security policies.

## 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/develop/app-objects-and-service-principals",
]
risk_score = 21
rule_id = "38e5acdd-5f20-4d99-8fe4-f0a1a592077f"
severity = "low"
tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Persistence", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:azure.auditlogs and azure.auditlogs.operation_name:"Add owner to service principal" and event.outcome:(Success or success)
'''


[[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.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 = "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/"

[metadata]
creation_date = "2025/03/11"
integration = ["endpoint", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
This rule detects the creation of files in the /var/log/ directory via process executables located in world-writeable
locations or via hidden processes. Attackers may attempt to hide their activities by creating files in the /var/log/
directory, which is commonly used for logging system events.
"""
from = "now-9m"
index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
language = "kuery"
license = "Elastic License v2"
name = "File Creation in /var/log via Suspicious Process"
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 File Creation in /var/log via Suspicious Process

In Linux environments, the `/var/log` directory is crucial for storing system logs, which are essential for monitoring and troubleshooting. Adversaries may exploit this by creating files in this directory using executables from insecure locations, aiming to conceal their activities. The detection rule identifies such suspicious file creations by monitoring processes from world-writable or hidden paths, flagging potential evasion tactics.

### Possible investigation steps

- Review the process executable path to determine if it originates from a world-writable or hidden location such as /tmp, /var/tmp, /dev/shm, or similar directories. This can indicate potential malicious activity.
- Examine the process name and its parent process to understand the context of the file creation and identify if it is associated with known legitimate or suspicious activities.
- Check the file path in /var/log to see if the created file has any unusual naming conventions or lacks a file extension, which might suggest an attempt to hide or disguise the file.
- Investigate the user account under which the process was executed to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior.
- Correlate the event with other logs or alerts from the same host to identify any related suspicious activities or patterns that could indicate a broader compromise.
- Assess the risk and impact of the file creation by considering the severity and risk score provided, and prioritize further actions based on this assessment.

### False positive analysis

- System maintenance scripts or legitimate applications may create temporary log files in /var/log using executables from directories like /tmp or /var/tmp. To handle this, identify and whitelist these known processes by their executable paths.
- Automated backup or monitoring tools might generate files in /var/log as part of their routine operations. Review these tools and exclude their processes from the rule to prevent unnecessary alerts.
- Development or testing environments often involve scripts that create log files in /var/log for debugging purposes. Consider excluding these environments from the rule or creating specific exceptions for known development processes.
- Some system updates or package installations might temporarily use world-writable directories for executable scripts that interact with /var/log. Monitor these activities and create exceptions for trusted update processes to reduce false positives.

### Response and remediation

- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
- Terminate any suspicious processes identified as originating from world-writable or hidden paths, especially those involved in file creation within /var/log.
- Conduct a thorough review of the files created in /var/log to determine if they contain malicious content or scripts, and remove any unauthorized files.
- Restore any affected system files or logs from a known good backup to ensure system integrity and continuity of logging.
- Implement stricter permissions on directories like /tmp, /var/tmp, and /dev/shm to prevent unauthorized execution of processes from these locations.
- Escalate the incident to the security operations team for further analysis and to determine if additional systems are compromised.
- Update and enhance monitoring rules to detect similar suspicious activities in the future, focusing on process execution from insecure locations and unauthorized file creation in critical directories.
"""
risk_score = 47
rule_id = "ddf26e25-3e30-42b2-92db-bde8eb82ad67"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

### Elastic Defend Integration Setup
Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.

#### Prerequisite Requirements:
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Tactic: Execution",
    "Tactic: Persistence",
    "Data Source: Elastic Defend",
    "Data Source: SentinelOne",
    "Data Source: Elastic Endgame",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"
query = '''
event.category:file and host.os.type:linux and event.action:(creation or file_create_event or file_rename_event or rename) and
(process.executable:(/tmp/* or /var/tmp/* or /dev/shm/* or ./* or /boot/*) or process.name:.*) and
file.path:/var/log/* and not file.extension:* and
not process.executable:("./usr/bin/podman" or "./install" or /tmp/vmis.*/install/vmware-installer/vmis-launcher or /tmp/ubuntu-release-upgrader-*)
'''

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

[[rule.threat.technique]]
id = "T1070"
name = "Indicator Removal"
reference = "https://attack.mitre.org/techniques/T1070/"

[[rule.threat.technique.subtechnique]]
id = "T1070.002"
name = "Clear Linux or Mac System Logs"
reference = "https://attack.mitre.org/techniques/T1070/002/"

[[rule.threat.technique]]
id = "T1564"
name = "Hide Artifacts"
reference = "https://attack.mitre.org/techniques/T1564/"

[[rule.threat.technique.subtechnique]]
id = "T1564.001"
name = "Hidden Files and Directories"
reference = "https://attack.mitre.org/techniques/T1564/001/"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

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

[[rule.threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"

[[rule.threat.technique.subtechnique]]
id = "T1059.004"
name = "Unix Shell"
reference = "https://attack.mitre.org/techniques/T1059/004/"

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

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

[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[rule.new_terms]
field = "new_terms_fields"
value = ["file.path", "process.executable"]

[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-5d"

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

[rule]
author = ["Elastic"]
description = """
Identifies when a service account is deleted in Google Cloud Platform (GCP). A service account is a special type of
account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to
make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users
through domain-wide delegation. An adversary may delete a service account in order to disrupt their target's business
operations.
"""
false_positives = [
    """
    Service accounts may be deleted by system administrators. Verify that the behavior was expected. Exceptions can be
    added to this rule to filter expected behavior.
    """,
]
index = ["filebeat-*", "logs-gcp*"]
language = "kuery"
license = "Elastic License v2"
name = "GCP Service Account Deletion"
note = """## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating GCP Service Account Deletion

In Google Cloud Platform, service accounts are crucial for enabling applications and VMs to perform authorized actions without user intervention. Adversaries may exploit this by deleting service accounts to disrupt operations or remove access. The detection rule monitors audit logs for successful service account deletions, flagging potential malicious activity to ensure timely investigation and response.

### Possible investigation steps

- Review the audit logs for the specific event.action:google.iam.admin.v*.DeleteServiceAccount to identify the exact time and source of the deletion.
- Identify the user or service account that initiated the deletion by examining the actor information in the audit logs.
- Check the event.dataset:gcp.audit logs for any preceding or subsequent actions by the same user or service account to determine if there is a pattern of suspicious activity.
- Investigate the context of the deleted service account, including its permissions and the resources it had access to, to assess the potential impact of its deletion.
- Contact the relevant team or individual responsible for the service account to verify if the deletion was authorized and intentional.
- If unauthorized, review access controls and consider implementing additional security measures to prevent future unauthorized deletions.

### False positive analysis

- Routine maintenance or updates may involve the deletion and recreation of service accounts. To manage this, create exceptions for known maintenance activities by excluding specific service account names or associated project IDs during these periods.
- Automated scripts or deployment tools might delete and recreate service accounts as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by filtering based on the user or service account executing the script.
- Organizational policy changes or restructuring can lead to legitimate service account deletions. Coordinate with the IT or security team to document these changes and adjust the detection rule to exclude these known events.
- Test environments often involve frequent creation and deletion of service accounts. Exclude test project IDs or environments from the detection rule to prevent unnecessary alerts.

### Response and remediation

- Immediately revoke any permissions associated with the deleted service account to prevent unauthorized access or actions by adversaries exploiting the deletion.
- Restore the deleted service account if possible, using GCP's undelete feature, to minimize disruption to business operations and restore normal functionality.
- Review and audit recent IAM activity logs to identify any unauthorized or suspicious actions that may have preceded or followed the service account deletion.
- Notify the security team and relevant stakeholders about the incident to ensure awareness and facilitate coordinated response efforts.
- Implement additional monitoring on critical service accounts to detect and alert on any further unauthorized deletion attempts.
- Conduct a root cause analysis to determine how the service account deletion was initiated and address any security gaps or misconfigurations that allowed it.
- Enhance access controls and consider implementing multi-factor authentication for actions involving service account management to prevent similar incidents in the future.

## Setup

The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = ["https://cloud.google.com/iam/docs/service-accounts"]
risk_score = 47
rule_id = "8fb75dda-c47a-4e34-8ecd-34facf7aad13"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Identity and Access Audit",
    "Tactic: Impact",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and event.action:google.iam.admin.v*.DeleteServiceAccount and event.outcome:success
'''


[[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/04/25"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
This rule detects the use of git to clone a repository or download files from GitHub using wget or curl, followed by
the creation of files in suspicious directories such as /tmp, /var/tmp, or /dev/shm. This behavior may indicate an
attempt to download a payload, exploit or tool.
"""
from = "now-9m"
index = ["logs-endpoint.events.process*", "logs-endpoint.events.file*"]
language = "eql"
license = "Elastic License v2"
name = "Git Repository or File Download to Suspicious Directory"
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 Git Repository or File Download to Suspicious Directory

Git, wget, and curl are essential tools for managing and transferring files in Linux environments. Adversaries exploit these tools to download malicious payloads into temporary directories like /tmp, /var/tmp, or /dev/shm, which are often overlooked. The detection rule identifies this behavior by monitoring for git clone commands or GitHub downloads followed by file creation in these directories, signaling potential threats.

### Possible investigation steps

- Review the process details, including process.entity_id and process.name, to confirm the execution of git, wget, or curl commands and verify if they align with expected usage patterns.
- Examine the process.command_line field to identify the specific GitHub URL or repository being accessed, and assess whether it is known or potentially malicious.
- Check the file creation event details, focusing on the file.path to determine the exact location and nature of the files created in /tmp, /var/tmp, or /dev/shm directories.
- Investigate the host.id and host.os.type to gather additional context about the affected system, including its role and any recent changes or anomalies.
- Correlate the timing of the process start and file creation events to understand the sequence of actions and identify any potential patterns or anomalies.
- Consult threat intelligence sources to determine if the accessed GitHub repository or downloaded files are associated with known threats or malicious activity.

### False positive analysis

- Development activities may trigger this rule when developers clone repositories or download files from GitHub into temporary directories for testing purposes. To manage this, create exceptions for specific user accounts or processes that are known to perform legitimate development tasks.
- Automated scripts or cron jobs that regularly update or download files from GitHub into temporary directories can also cause false positives. Identify these scripts and exclude their process IDs or command patterns from the rule.
- System maintenance tasks that involve downloading updates or patches into temporary directories might be flagged. Coordinate with system administrators to identify these tasks and whitelist the associated processes or directories.
- Security tools or monitoring solutions that download threat intelligence feeds or other data into temporary directories could be mistakenly identified. Verify these tools and exclude their activities from the rule to prevent unnecessary alerts.

### Response and remediation

- Immediately isolate the affected system to prevent further potential malicious activity and lateral movement within the network.
- Terminate any suspicious processes related to git, wget, or curl that are actively running and associated with the creation of files in the /tmp, /var/tmp, or /dev/shm directories.
- Conduct a thorough examination of the files created in these directories to identify and remove any malicious payloads or tools.
- Restore any compromised files or systems from clean backups to ensure the integrity of the affected system.
- Implement network monitoring to detect and block any unauthorized outbound connections to suspicious domains, particularly those related to GitHub or other code repositories.
- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems may be affected.
- Update endpoint protection and intrusion detection systems to enhance detection capabilities for similar threats, focusing on the specific indicators of compromise identified in this alert.
"""
risk_score = 21
rule_id = "70089609-c41a-438e-b132-5b3b43c5fc07"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

### Elastic Defend Integration Setup
Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.

#### Prerequisite Requirements:
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).

Elastic Defend integration does not collect environment variable logging by default.
In order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration.
 #### To set up environment variable capture for an Elastic Agent policy:
- Go to “Security → Manage → Policies”.
- Select an “Elastic Agent policy”.
- Click “Show advanced settings”.
- Scroll down or search for “linux.advanced.capture_env_vars”.
- Enter the names of environment variables you want to capture, separated by commas.
- For this rule the linux.advanced.capture_env_vars variable should be set to "HTTP_PROXY,HTTPS_PROXY,ALL_PROXY".
- Click “Save”.
After saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly.
For more information on capturing environment variables refer to the [helper guide](https://www.elastic.co/guide/en/security/current/environment-variable-capture.html).
"""
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Command and Control",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
type = "eql"
query = '''
sequence by process.entity_id, host.id with maxspan=10s
  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
     (process.name == "git" and process.args == "clone") or
     (process.name in ("wget", "curl") and process.command_line like~ "*github*")
  ) and not (
    process.parent.name in ("git", "cmake") or
     process.parent.args like "/root/.ansible/tmp/ansible*"
  )]
  [file where host.os.type == "linux" and event.type == "creation" and file.path like ("/tmp/*", "/var/tmp/*", "/dev/shm/*")]
'''

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

[[rule.threat.technique]]
id = "T1071"
name = "Application Layer Protocol"
reference = "https://attack.mitre.org/techniques/T1071/"

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

[[rule.threat.technique]]
id = "T1105"
name = "Ingress Tool Transfer"
reference = "https://attack.mitre.org/techniques/T1105/"

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