Elastic rules: 27

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

[rule]
author = ["Elastic"]
description = """
Detects the creation of an AWS IAM Roles Anywhere Trust Anchor that uses an external certificate authority (CA) rather
than an AWS-managed Certificate Manager Private CA (ACM PCA). While Roles Anywhere enables secure, short-term credential
issuance for workloads outside AWS, adversaries can exploit this feature by registering their own external CA as a
trusted root. This allows them to generate valid client certificates that persistently authenticate to AWS roles from
any location, even after key rotation or credential revocation events. This rule helps detect persistence or
unauthorized federation attempts by flagging trust anchors configured with non-AWS CAs.
"""
event_category_override = "event.type"
false_positives = [
    """
    AWS IAM Roles Anywhere Trust Anchors are legitimate profiles that can be created by administrators to allow access
    from any location. Ensure that the trust anchor is created by a legitimate administrator and that the external
    certificate authority is authorized.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "eql"
license = "Elastic License v2"
name = "AWS IAM Roles Anywhere Trust Anchor Created with External CA"
note = """## Triage and analysis

### Investigating AWS IAM Roles Anywhere Trust Anchor Created with External CA

AWS IAM Roles Anywhere allows workloads outside AWS (such as on-premises servers or CI/CD agents) to assume AWS IAM roles by presenting X.509 certificates. A trust anchor defines which certificate authority (CA) AWS trusts to validate 
these external identities. Normally, organizations use AWS Certificate Manager Private CA (ACM PCA) to control issuance 
and revocation. 

This detection rule identifies when a trust anchor is created using an **external CA** (`sourceType= "CERTIFICATE_BUNDLE" or "SELF_SIGNED_REPOSITORY"`) rather than an ACM-managed CA (`sourceType="AWS_ACM_PCA"`). This can indicate an adversary establishing persistent external access, enabling them to authenticate using certificates signed by their own CA.

#### Possible investigation steps

- **Identify the actor**
  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`.
  - Determine whether this user or role is normally responsible for IAM configuration or Roles Anywhere setup.

- **Review the trust anchor details**
  - In `aws.cloudtrail.request_parameters`, confirm the `sourceType` and inspect the certificate chain.
  - Look for non-AWS issuer names, custom organization fields, or self-signed CA certificates.

- **Assess the scope and risk**
  - Identify which IAM roles are linked to this trust anchor via `Profile` associations.
  - Determine whether any of those roles provide privileged or cross-account access.
  - Check for subsequent API calls like `CreateProfile`, `CreateRole`, or `AssumeRoleWithCertificate` to gauge whether 
    the external CA has been used.

- **Correlate related activity**
  - Search for preceding reconnaissance or setup activity:
    - `ListTrustAnchors`, `ListProfiles`, `GetRole`
    - Attempts to create additional credential paths (`CreateAccessKey`, `CreateOpenIDConnectProvider`)
  - Investigate other actions by the same user identity, particularly IAM role or trust policy modifications.

- **Validate legitimacy**
  - Confirm with identity management or security engineering teams whether the external CA is an approved authority.
  - Review internal PKI or certificate inventories to ensure this CA is registered in the organization’s trust chain.

### False positive analysis

- **Legitimate external CA use**
  - Some organizations integrate trusted third-party PKI providers (e.g., Venafi, DigiCert, Entrust) for workload identity management. Validate whether the CA is part of your documented PKI ecosystem.
- **Testing and lab accounts**
  - Development or testing environments may temporarily use self-signed certificates to validate Roles Anywhere integrations.
  - Confirm that such activity occurs in isolated accounts and not in production.
- **Expected administrative setup**
  - Initial configuration by security engineers or platform teams may trigger this rule. Verify via change tickets or 
    deployment logs before treating as suspicious.

### Response and remediation

- **Containment**
  - If the CA is unauthorized, immediately delete the trust anchor using 
    `aws rolesanywhere delete-trust-anchor --trust-anchor-id <id>`.
  - Review for any certificates already used to assume roles and revoke those certificates from the external CA.

- **Investigation**
  - Identify all IAM Roles Anywhere profiles linked to the trust anchor (`ListProfiles`).
  - Check CloudTrail for any successful `AssumeRoleWithCertificate` calls associated with the external CA.
  - Assess whether lateral movement or data exfiltration occurred after the trust anchor creation.

- **Recovery and hardening**
  - Replace unauthorized CAs with ACM PCA-managed ones.
  - Restrict `rolesanywhere:CreateTrustAnchor` permissions to security administrators only.
  - Monitor for new trust anchor creations and external certificate sources via AWS Config rules or Security Hub findings.
  - Implement GuardDuty or Security Hub integrations to detect anomalous IAM and Roles Anywhere behavior.

### Additional information

- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
"""
references = [
    "https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html",
    "https://ermetic.com/blog/aws/keep-your-iam-users-close-keep-your-third-parties-even-closer-part-1/",
    "https://docs.aws.amazon.com/rolesanywhere/latest/APIReference/API_CreateTrustAnchor.html",
]
risk_score = 47
rule_id = "71de53ea-ff3b-11ee-b572-f661ea17fbce"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS IAM",
    "Use Case: Identity and Access Audit",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
info where data_stream.dataset == "aws.cloudtrail"
  and event.provider == "rolesanywhere.amazonaws.com"
  and event.action == "CreateTrustAnchor"
  and event.outcome == "success"
  and not stringContains(aws.cloudtrail.request_parameters, "sourceType=AWS_ACM_PCA")
'''


[[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.technique]]
id = "T1556"
name = "Modify Authentication Process"
reference = "https://attack.mitre.org/techniques/T1556/"

[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user_agent.original",
    "source.ip",
    "aws.cloudtrail.user_identity.arn",
    "aws.cloudtrail.user_identity.type",
    "aws.cloudtrail.user_identity.access_key_id",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
    "aws.cloudtrail.response_elements",
]

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

[rule]
author = ["Elastic", "Austin Songer"]
description = """
Identifies when a service has assumed a role in AWS Security Token Service (STS). Services can assume a role to obtain
temporary credentials and access AWS resources. Adversaries can use this technique for credential access and privilege
escalation. This is a New Terms rule that identifies when a service assumes a role in AWS Security Token Service (STS)
to obtain temporary credentials and access AWS resources. While often legitimate, adversaries may use this technique for
unauthorized access, privilege escalation, or lateral movement within an AWS environment.
"""
false_positives = [
    """
    AWS administrators or automated processes might regularly assume roles for legitimate administrative purposes. AWS
    services might assume roles to access AWS resources as part of their standard operations. Automated workflows might
    assume roles to perform periodic tasks such as data backups, updates, or deployments.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS STS Role Assumption by Service"
note = """## Triage and analysis

### Investigating AWS STS Role Assumption by Service

This rule identifies instances where AWS STS (Security Token Service) is used to assume a role, granting temporary credentials for AWS resource access. While this action is often legitimate, it can be exploited by adversaries to obtain unauthorized access, escalate privileges, or move laterally within an AWS environment.

#### Possible Investigation Steps

- **Identify the Actor and Assumed Role**:
  - **User Identity**: Review the `aws.cloudtrail.user_identity.invoked_by` field to determine which service initiated the `AssumeRole` action.
  - **Role Assumed**: Check the `aws.cloudtrail.resources.arn` field to confirm the assumed role and ensure it aligns with expected responsibilities.
  - **Session Name**: Observe the `aws.cloudtrail.flattened.request_parameters.roleSessionName` for context on the session's intended purpose, if available.
 - **Expiration Time**: Verify `aws.cloudtrail.flattened.response_elements.credentials.expiration` to determine when the credentials expire or expired.

- **Inspect the User Agent for Tooling Identification**:
  - **User Agent Details**: Review the `user_agent.original` field to identify the tool or SDK used for the role assumption. Indicators include:
    - **AWS SDKs (e.g., Boto3)**: Often used in automated workflows or scripts.
    - **AWS CLI**: Suggests command-line access, potentially indicating direct user interaction.
    - **Custom Tooling**: Unusual user agents may signify custom or suspicious tools.

- **Contextualize with Related Events**:
  - **Review Event Patterns**: Check surrounding CloudTrail events to see if other actions coincide with this `AssumeRole` activity, such as attempts to access sensitive resources.
  - **Identify High-Volume Exceptions**: Due to the potential volume of `AssumeRole` events, determine common, legitimate `roleArn` values or `user_agent` patterns, and consider adding these as exceptions to reduce noise.

- **Evaluate the Privilege Level of the Assumed Role**:
  - **Permissions**: Inspect permissions associated with the assumed role to understand its access level.
  - **Authorized Usage**: Confirm whether the role is typically used for administrative purposes and if the assuming entity frequently accesses it as part of regular responsibilities.

### False Positive Analysis

- **Automated Workflows and Applications**: Many applications or scheduled tasks may assume roles for standard operations. Check user agents and ARNs for consistency with known workflows.
- **Routine AWS Service Actions**: Historical data may reveal if the same service assumes new roles regularly as part of authorized operations.

### Response and Remediation

- **Revoke Unauthorized Sessions**: If unauthorized, consider revoking the session by adjusting IAM policies or permissions associated with the assumed role.
- **Enhance Monitoring and Alerts**: Set up enhanced monitoring for high-risk roles, especially those with elevated privileges.
- **Manage Exceptions**: Regularly review and manage high-frequency roles and user agent patterns, adding trusted ARNs and user agents to exception lists to minimize alert fatigue.
- **Incident Response**: If malicious behavior is identified, follow incident response protocols, including containment, investigation, and remediation.

### Additional Information

For more information on managing and securing AWS STS, refer to the [AWS STS documentation](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) and AWS security best practices.
"""
references = ["https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html"]
risk_score = 21
rule_id = "93075852-b0f5-4b8b-89c3-a226efae5726"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS STS",
    "Resources: Investigation Guide",
    "Use Case: Identity and Access Audit",
    "Tactic: Privilege Escalation",
    "Tactic: Lateral Movement",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "sts.amazonaws.com"
    and event.action: "AssumeRole"
    and event.outcome: "success"
    and aws.cloudtrail.user_identity.type: "AWSService"
    and aws.cloudtrail.user_identity.invoked_by: (
          "ec2.amazonaws.com" or
          "lambda.amazonaws.com" or
          "rds.amazonaws.com" or
          "ssm.amazonaws.com" or
          "ecs-tasks.amazonaws.com" or
          "ecs.amazonaws.com" or
          "eks.amazonaws.com" or
          "eks-fargate.amazonaws.com" or
          "codepipeline.amazonaws.com" or
          "codebuild.amazonaws.com" or
          "autoscaling.amazonaws.com")
'''


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

[[rule.threat.technique]]
id = "T1548"
name = "Abuse Elevation Control Mechanism"
reference = "https://attack.mitre.org/techniques/T1548/"

[[rule.threat.technique.subtechnique]]
id = "T1548.005"
name = "Temporary Elevated Cloud Access"
reference = "https://attack.mitre.org/techniques/T1548/005/"

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

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

[[rule.threat.technique]]
id = "T1550"
name = "Use Alternate Authentication Material"
reference = "https://attack.mitre.org/techniques/T1550/"

[[rule.threat.technique.subtechnique]]
id = "T1550.001"
name = "Application Access Token"
reference = "https://attack.mitre.org/techniques/T1550/001/"

[rule.threat.tactic]
id = "TA0008"
name = "Lateral Movement"
reference = "https://attack.mitre.org/tactics/TA0008/"
[rule.investigation_fields]
field_names = [
    "@timestamp",
    "source.address",
    "user_agent.original",
    "aws.cloudtrail.user_identity.invoked_by",
    "aws.cloudtrail.user_identity.type",
    "aws.cloudtrail.flattened.response_elements.credentials.accessKeyId",
    "event.action",
    "event.outcome",
    "aws.cloudtrail.resources.arn",
    "aws.cloudtrail.resources.type",
    "aws.cloudtrail.flattened.request_parameters.roleSessionName",
    "cloud.region",
    "cloud.account.id",
    "aws.cloudtrail.request_parameters",
    "aws.cloudtrail.response_elements",
]

[rule.new_terms]
field = "new_terms_fields"
value = ["aws.cloudtrail.user_identity.invoked_by", "aws.cloudtrail.resources.arn"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-5d"

[rule]
description = """
Detects when SSH accesses crypto wallet or web browser files on a macOS system like crypto wallet files, or web browser
cookies.
"""
id = "c9d50139-81c9-4080-a091-0c18eed50b11"
license = "Elastic License v2"
name = "Crypto Wallet or Web Browser File Access via SSH"
os_list = ["macos"]
version = "1.0.3"

query = '''
file where event.action == "open" and (process.name in ("ssh", "sshd", "sshd-session") or Effective_process.name in ("ssh", "sshd", "sshd-session")) 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")) and 
 not file.path like~ "/Users/*/Library/Application Support/Slack/Cookies"
'''

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"

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

[rule]
author = ["Elastic"]
description = """
This rule identifies the creation of directories in the /bin directory. The /bin directory contains essential binary
files that are required for the system to function properly. The creation of directories in this location could be an
attempt to hide malicious files or executables, as these /bin directories usually just contain binaries.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Directory Creation in /bin 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 Directory Creation in /bin directory

The /bin directory is crucial for Linux systems, housing essential binaries for system operations. Adversaries may exploit this by creating directories here to conceal malicious files, leveraging the directory's trusted status. The detection rule identifies suspicious directory creation by monitoring 'mkdir' executions in critical binary paths, excluding legitimate system operations, thus flagging potential threats for further investigation.

### Possible investigation steps

- Review the process details to confirm the execution of 'mkdir' in the specified critical binary paths such as /bin, /usr/bin, /usr/local/bin, /sbin, /usr/sbin, and /usr/local/sbin.
- Check the parent process of the 'mkdir' command to determine if it was initiated by a legitimate system process or a potentially malicious one.
- Investigate the user account associated with the 'mkdir' process to assess if it has the necessary permissions and if the activity aligns with the user's typical behavior.
- Examine the system logs around the time of the directory creation for any other suspicious activities or anomalies that might indicate a broader attack.
- Verify if any files or executables have been placed in the newly created directory and assess their legitimacy and potential threat level.
- Cross-reference the event with threat intelligence sources to identify if the activity matches any known malicious patterns or indicators of compromise.

### False positive analysis

- System updates or package installations may trigger directory creation in the /bin directory as part of legitimate operations. Users can mitigate this by creating exceptions for known package management processes like apt, yum, or rpm.
- Custom scripts or administrative tasks that require creating directories in the /bin directory for temporary storage or testing purposes can also lead to false positives. Users should document and exclude these specific scripts or tasks from the detection rule.
- Automated deployment tools or configuration management systems such as Ansible, Puppet, or Chef might create directories in the /bin directory as part of their setup routines. Users should identify these tools and add them to the exclusion list to prevent unnecessary alerts.
- Development or testing environments where developers have permissions to create directories in the /bin directory for application testing can result in false positives. Users should differentiate between production and non-production environments and apply the rule accordingly.

### Response and remediation

- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary.
- Terminate any suspicious processes related to the directory creation in the /bin directory to halt any ongoing malicious activity.
- Conduct a thorough review of the newly created directories and files within the /bin directory to identify and remove any malicious binaries or scripts.
- Restore any altered or deleted legitimate binaries from a known good backup to ensure system integrity and functionality.
- Implement file integrity monitoring on critical system directories, including /bin, to detect unauthorized changes in real-time.
- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
- Review and update access controls and permissions for the /bin directory to restrict unauthorized directory creation and enhance security posture."""
risk_score = 21
rule_id = "3302835b-0049-4004-a325-660b1fba1f67"
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",
    "Tactic: Persistence",
    "Data Source: Elastic Defend",
    "Data Source: Crowdstrike",
    "Data Source: SentinelOne",
    "Data Source: Elastic Endgame",
    "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", "start", "ProcessRollup2", "exec_event") and process.name == "mkdir" and
process.args like ("/bin/*", "/usr/bin/*", "/usr/local/bin/*", "/sbin/*", "/usr/sbin/*", "/usr/local/sbin/*") and
not process.args in ("/bin/mkdir", "/usr/bin/mkdir", "/usr/local/bin/mkdir", "/usr/local/bin/cursor", "/usr/bin/coreutils") and
not process.parent.executable in ("/usr/bin/make", "/bin/make")
'''

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

[[rule.threat.technique]]
id = "T1036"
name = "Masquerading"
reference = "https://attack.mitre.org/techniques/T1036/"

[[rule.threat.technique.subtechnique]]
id = "T1036.005"
name = "Match Legitimate Resource Name or Location"
reference = "https://attack.mitre.org/techniques/T1036/005/"

[[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.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"

[metadata]
creation_date = "2022/05/23"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/08/17"

[rule]
author = ["Elastic"]
description = """
Identifies the Elastic endpoint agent has stopped and is no longer running on the host. Adversaries may attempt to
disable security monitoring tools in an attempt to evade detection or prevention capabilities during an intrusion. This
may also indicate an issue with the agent itself and should be addressed to ensure defensive measures are back in a
stable state.
"""
from = "now-9m"
index = ["logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Elastic Agent Service Terminated"
risk_score = 47
rule_id = "b627cd12-dac4-11ec-9582-f661ea17fbcd"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "OS: Windows",
    "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 event.type == "start" and
(
  /* net, sc or wmic stopping or deleting Elastic Agent on Windows */
  (
    process.name : ("net.exe", "sc.exe", "wmic.exe", "powershell.exe", "taskkill.exe", "PsKill.exe", "ProcessHacker.exe") and
    process.args : ("stopservice", "uninstall", "stop", "disabled", "Stop-Process", "terminate", "suspend") and
    process.args : ("elasticendpoint", "Elastic Agent", "elastic-agent", "elastic-endpoint")
  ) or

  /* direct uninstallation of Elastic Agent or Elastic Endpoint on Windows */
  (
    host.os.type == "windows" and
    process.name : ("elastic-agent.exe", "endpoint-security.exe", "elastic-endpoint.exe") and
    process.args : "uninstall" and
    /* exclude legitimate Elastic-managed reinstall, upgrade, and uninstall subprocesses */
    not (
      process.parent.code_signature.trusted == true and
      process.parent.code_signature.subject_name == "Elasticsearch, Inc." and
      (
        (
          process.name : "elastic-agent.exe" and process.args : "--force" and
          process.parent.name : "elastic-agent.exe" and process.parent.args : "install" and
          process.parent.args : ("--force", "-f")
        ) or
        (
          process.parent.name : "endpoint-security.exe" and
          process.executable : "*\\components\\previous\\elastic-endpoint.exe" and
          process.args : "--keepstate" and process.parent.args : "--upgrade"
        ) or
        (
          process.name : "endpoint-security.exe" and process.parent.name : "elastic-agent.exe" and
          process.parent.args : "uninstall"
        )
      )
    )
  ) or

  /* service or systemctl used to stop Elastic Agent on Linux */
  (
    process.name in ("systemctl", "service", "chkconfig", "update-rc.d") and
    process.args : ("elastic-agent", "elastic-agent.service", "ElasticEndpoint") and
    process.args : ("stop", "disable", "remove", "off", "kill", "mask") and
    not (
      process.parent.executable : "/opt/Elastic/Agent/data/elastic-agent-*/components/previous/elastic-endpoint" and
      process.parent.args : "uninstall" and
      process.parent.args : "--keepstate"
    )
  ) or
  
  /* pkill, killall used to stop Elastic Agent or Endpoint on Linux */
  (process.name in ("pkill", "killall", "kill") and process.args : ("elastic-agent", "elastic-endpoint")) or

  /* Unload Elastic Defend extension on MacOS */
  (process.name : "kextunload" and process.args : "com.apple.iokit.EndpointSecurity")
)
'''

setup = """## Setup

This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend
"""

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 Elastic Agent Service Terminated

The Elastic Agent is a crucial component for monitoring and securing endpoints across various operating systems. It ensures continuous security oversight by collecting and analyzing data. Adversaries may attempt to disable this agent to evade detection, compromising system defenses. The detection rule identifies suspicious termination activities by monitoring specific processes and commands across Windows, Linux, and macOS, flagging potential defense evasion attempts.

### Possible investigation steps

- Review the event logs to identify the exact process and command used to terminate the Elastic Agent, focusing on the process names and arguments such as "net.exe", "sc.exe", "systemctl", and "pkill" with arguments like "stop", "uninstall", or "disable".
- Check the timeline of events around the termination to identify any preceding suspicious activities or anomalies that might indicate an adversary's presence or actions.
- Investigate the user account associated with the process termination to determine if it was authorized or if there are signs of account compromise.
- Examine the host for any other signs of tampering or compromise, such as unauthorized changes to system configurations or the presence of other malicious processes.
- Verify the current status of the Elastic Agent on the affected host and attempt to restart it if it is not running, ensuring that security monitoring is restored.
- Correlate this event with other alerts or logs from the same host or network to identify potential patterns or coordinated attack activities.

### False positive analysis

- Routine maintenance activities may trigger the rule if administrators use commands like systemctl or service to stop the Elastic Agent for updates or configuration changes. To manage this, create exceptions for known maintenance windows or authorized personnel.
- Automated scripts or deployment tools that temporarily disable the Elastic Agent during software installations or updates can cause false positives. Identify these scripts and whitelist their execution paths or specific arguments.
- Testing environments where Elastic Agent is frequently started and stopped for development purposes might generate alerts. Exclude these environments by specifying their hostnames or IP addresses in the rule exceptions.
- Security tools or processes that interact with the Elastic Agent, such as backup solutions or system monitoring tools, might inadvertently stop the service. Review these interactions and adjust the rule to ignore specific process names or arguments associated with these tools.
- User-initiated actions, such as troubleshooting or system performance optimization, may involve stopping the Elastic Agent. Educate users on the impact of these actions and establish a protocol for notifying the security team when such actions are necessary.

### Response and remediation

- Immediately isolate the affected host from the network to prevent further unauthorized access or potential lateral movement by adversaries.
- Verify the status of the Elastic Agent on the affected host and attempt to restart the service. If the service fails to restart, investigate potential causes such as corrupted files or missing dependencies.
- Conduct a thorough review of recent process execution logs on the affected host to identify any unauthorized or suspicious activities that may have led to the termination of the Elastic Agent.
- If malicious activity is confirmed, perform a comprehensive malware scan and remove any identified threats. Ensure that the host is clean before reconnecting it to the network.
- Review and update endpoint security configurations to prevent unauthorized termination of security services. This may include implementing stricter access controls or using application whitelisting.
- Escalate the incident to the security operations team for further analysis and to determine if additional hosts are affected or if there is a broader security incident underway.
- Document the incident, including all actions taken and findings, to enhance future response efforts and update incident response plans as necessary."""

[[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 = "2025/06/17"
integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel", "cloud_defend"]
maturity = "production"
min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
min_stack_version = "9.3.0"
updated_date = "2026/03/30"

[rule]
author = ["Elastic"]
description = """
This rule detects the use of the "kubectl auth --can-i" command, which is used to check permissions in Kubernetes clusters.
Attackers may use this command to enumerate permissions and discover potential misconfigurations in the cluster, allowing
them to gain unauthorized access or escalate privileges.
"""
from = "now-9m"
index = [
    "auditbeat-*",
    "endgame-*",
    "logs-auditd_manager.auditd-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-cloud_defend.process*",
]
language = "eql"
license = "Elastic License v2"
name = "Kubectl Permission Discovery"
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 Kubectl Permission Discovery

Kubectl is a command-line tool for interacting with Kubernetes clusters, allowing users to manage applications and resources. Adversaries may exploit the "kubectl auth can-i" command to probe for permission misconfigurations, potentially leading to unauthorized access or privilege escalation. The detection rule identifies this activity by monitoring specific command executions on Linux and macOS systems, flagging potential misuse for further investigation.

### Possible investigation steps

- Review the process execution details to confirm the use of the "kubectl auth can-i" command, focusing on the process name "kubectl" and arguments "auth" and "can-i".
- Identify the user account associated with the execution of the command to determine if it aligns with expected administrative activity or if it indicates potential unauthorized access.
- Check the timing and frequency of the command execution to assess whether it corresponds with routine operations or suggests suspicious behavior.
- Investigate the source IP address or hostname from which the command was executed to verify if it originates from a known and trusted environment.
- Examine related logs and events around the time of the alert to identify any subsequent actions that might indicate privilege escalation or unauthorized access attempts.
- Cross-reference the alert with any recent changes or incidents in the Kubernetes cluster to determine if the command execution is part of a broader security concern.

### False positive analysis

- Routine administrative checks by authorized personnel can trigger the rule. To manage this, create exceptions for specific user accounts or roles that regularly perform these checks as part of their job duties.
- Automated scripts or monitoring tools that verify permissions as part of their normal operation may cause false positives. Identify these scripts and whitelist their execution paths or associated service accounts.
- Development and testing environments where developers frequently check permissions might lead to alerts. Consider excluding these environments from the rule or adjusting the risk score for these specific contexts.
- Scheduled audits or compliance checks that involve permission verification can be mistaken for malicious activity. Document these activities and set up time-based exceptions to prevent unnecessary alerts during known audit periods.

### Response and remediation

- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or privilege escalation.
- Revoke any suspicious or unauthorized credentials or tokens identified during the investigation to prevent further misuse.
- Conduct a thorough review of the Kubernetes Role-Based Access Control (RBAC) configurations to identify and rectify any permission misconfigurations.
- Implement stricter access controls and least privilege principles for Kubernetes users and service accounts to minimize the risk of unauthorized access.
- Monitor for any additional suspicious activity or anomalies in the cluster, focusing on access patterns and command executions.
- Escalate the incident to the security operations team for further analysis and to determine if additional clusters or systems are affected.
- Update detection and monitoring systems to enhance visibility and alerting for similar permission discovery attempts in the future.
"""
references = [
    "https://kubernetes.io/docs/reference/kubectl/generated/kubectl_auth/kubectl_auth_can-i/",
    ]
risk_score = 47
rule_id = "1600f9e2-5be6-4742-8593-1ba50cd94069"
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 or 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, 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",
  "Domain: Container",
  "Domain: Kubernetes",
  "OS: Linux",
  "OS: macOS",
  "Use Case: Threat Detection",
  "Tactic: Discovery",
  "Data Source: Elastic Defend",
  "Data Source: Elastic Endgame",
  "Data Source: Auditd Manager",
  "Data Source: Crowdstrike",
  "Data Source: SentinelOne",
  "Data Source: Elastic Defend for Containers",
  "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type in ("linux", "macos") and event.type == "start" and
event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
process.name == "kubectl" and process.args == "auth" and process.args == "can-i"
'''

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

[[rule.threat.technique]]
id = "T1069"
name = "Permission Groups Discovery"
reference = "https://attack.mitre.org/techniques/T1069/"

[[rule.threat.technique]]
id = "T1613"
name = "Container and Resource Discovery"
reference = "https://attack.mitre.org/techniques/T1613/"

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

[metadata]
creation_date = "2026/02/02"
integration = ["kubernetes"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
This rule detects attempts to create, update, or patch pods by an anonymous user. An anonymous user is a user that
is not authenticated or authorized to access the Kubernetes API server. Creating, updating, or patching pods is a common
activity for attackers to gain access to the cluster and execute commands.
"""
index = ["logs-kubernetes.audit_logs-*"]
language = "eql"
license = "Elastic License v2"
name = "Kubernetes Anonymous User Create/Update/Patch Pods Request"
risk_score = 47
rule_id = "3a01e5c6-ce01-46d7-ac9f-52dc349695fb"
severity = "medium"
tags = [
    "Data Source: Kubernetes",
    "Domain: Kubernetes",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Resources: Investigation Guide"
    ]
timestamp_override = "event.ingested"
type = "eql"
query = '''
any where data_stream.dataset == "kubernetes.audit_logs" and (
    kubernetes.audit.user.username in ("system:anonymous", "system:unauthenticated") or
    kubernetes.audit.user.username == null or
    kubernetes.audit.user.username == ""
  ) and kubernetes.audit.level in ("RequestResponse", "ResponseComplete", "Request") and kubernetes.audit.verb in ("create", "update", "patch") and
kubernetes.audit.objectRef.resource == "pods"

'''

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

[[rule.threat.technique]]
id = "T1610"
name = "Deploy Container"
reference = "https://attack.mitre.org/techniques/T1610/"

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

[metadata]
creation_date = "2024/06/19"
integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defender", "system", "crowdstrike"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
Identifies attempts to open a Microsoft Management Console File from untrusted paths. Adversaries may use MSC files for
initial access and execution.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
]
language = "eql"
license = "Elastic License v2"
name = "Microsoft Management Console File from Unusual Path"
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 Microsoft Management Console File from Unusual Path

Microsoft Management Console (MMC) is a Windows utility that provides a framework for system management. Adversaries may exploit MMC by executing .msc files from non-standard directories to bypass security controls. The detection rule identifies such anomalies by monitoring the execution of mmc.exe with .msc files from untrusted paths, flagging potential unauthorized access or execution attempts.

### Possible investigation steps

- Review the process execution details to confirm the path of the mmc.exe and the .msc file being executed. Check if the path is indeed non-standard or untrusted as per the query criteria.
- Investigate the origin of the .msc file by examining file creation and modification timestamps, and check for any recent changes or unusual activity in the directory where the file resides.
- Analyze the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it appears suspicious.
- Check for any related alerts or logs around the same timeframe that might indicate lateral movement or other malicious activities, such as unusual network connections or file access patterns.
- Correlate the event with other data sources mentioned in the rule, such as Microsoft Defender XDR or Crowdstrike, to gather additional context or corroborating evidence of potential malicious activity.
- Assess the risk and impact of the execution by determining if the .msc file has any known malicious signatures or if it attempts to perform unauthorized actions on the system.

### False positive analysis

- Legitimate administrative tasks may trigger this rule if system administrators execute .msc files from custom directories. To manage this, create exceptions for known administrative scripts or tools that are regularly used from non-standard paths.
- Software installations or updates might involve executing .msc files from temporary or installation directories. Monitor these activities and whitelist specific installation paths if they are verified as safe and part of routine operations.
- Automated scripts or third-party management tools could execute .msc files from non-standard locations as part of their normal operation. Identify these tools and add their execution paths to the exception list to prevent unnecessary alerts.
- Development or testing environments may involve running .msc files from various directories for testing purposes. Establish a separate monitoring policy for these environments or exclude known development paths to reduce false positives.

### Response and remediation

- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
- Terminate any suspicious processes related to mmc.exe executing from untrusted paths to halt potential malicious activity.
- Conduct a thorough review of the system's recent activity logs to identify any additional indicators of compromise or related suspicious activities.
- Remove any unauthorized .msc files found in non-standard directories and ensure they are not reintroduced.
- Restore the system from a known good backup if any unauthorized changes or damage is detected.
- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
references = ["https://www.elastic.co/security-labs/grimresource"]
risk_score = 47
rule_id = "7e23dfef-da2c-4d64-b11d-5f285b638853"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: SentinelOne",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Windows Security Event Logs",
    "Data Source: Crowdstrike",
    "Resources: Investigation Guide",
    "Data Source: Sysmon",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and
  process.executable : (
    "?:\\Windows\\System32\\mmc.exe",

    /* Crowdstrike specific condition as it uses NT Object paths */
    "\\Device\\HarddiskVolume*\\Windows\\System32\\mmc.exe"
  ) and
  process.args : "*.msc" and
  not process.args : (
        "?:\\Windows\\System32\\*.msc",
        "?:\\Windows\\SysWOW64\\*.msc",
        "?:\\Program files\\*.msc",
        "?:\\Program Files (x86)\\*.msc",
        "?:\\Windows\\ADFS\\Microsoft.IdentityServer.msc"
  ) and
  not process.command_line : (
    "C:\\Windows\\system32\\mmc.exe eventvwr.msc /s",
    "mmc.exe eventvwr.msc /s",
    "\"C:\\Windows\\System32\\mmc.exe\" CompMgmt.msc*"
  )
'''

setup = """## Setup

This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

### Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

- [CrowdStrike](https://ela.st/crowdstrike-integration)
- [Microsoft Defender XDR](https://ela.st/m365-defender)
- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
"""


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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1204.002"
name = "Malicious File"
reference = "https://attack.mitre.org/techniques/T1204/002/"

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

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

[[rule.threat.technique]]
id = "T1218"
name = "System Binary Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1218/"

[[rule.threat.technique.subtechnique]]
id = "T1218.014"
name = "MMC"
reference = "https://attack.mitre.org/techniques/T1218/014/"

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

[rule]
description = """
Identifies the execution of the grep, egrep, fgrep or pgrep commands with a multi-value search pattern to collect
sensitive information. This is a common technique used by attackers to collect sensitive information from the system.
"""
id = "2d00bedd-28aa-4a54-a1e0-92fa00765540"
license = "Elastic License v2"
name = "Multi-Value Secret Searching via Grep"
os_list = ["linux"]
reference = [
    "https://socket.dev/blog/10-npm-typosquatted-packages-deploy-credential-harvester",
    "https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/",
    "https://www.virustotal.com/gui/file/71e35aef03099cd1f2d6446734273025a163597de93912df321ef118bf135238",
]
version = "1.0.5"

query = '''
sequence by process.parent.entity_id with maxspan=10s
  [process where event.type == "start" and event.action == "exec" and process.name in ("grep", "egrep", "fgrep", "pgrep") and
  process.command_line regex~ """.*\([a-z]{1,15}\|[a-z]{1,15}.*\).*""" and
  process.command_line like~ (
    "*|pem*", "*pem|*", "*|key*", "*key|*", "*|cred*", "*cred|*", "*|db*", "*db|*", "*|sqlite*", "*sqlite|*", "*|ssh*", "*ssh|*",
    "*|conf*", "*conf|*", "*|cnf*", "*cnf|*",  "*|ini*", "*ini|*", "*|secret*", "*secret|*", "*|token*", "*token|*",
    "*|auth*", "*auth|*", "*|passwd*",  "*passwd|*", "*|shadow*", "*shadow|*", "*|env*", "*env|*", "*|database*", "*database|*",
    "*|mysql*", "*mysql|*", "*|postgres*", "*postgres|*", "*|mongo*", "*mongo|*", "*|redis*", "*redis|*", "*|vault*", "*vault|*"
  ) and
  not (
    (
      process.parent.args like ("/var/tmp/rpm-tmp*", "/usr/openv/netbackup/bin/private/nb_init_cfg") and
      process.command_line like "*/tmp/NBInstallAnswer.conf"
    ) or
    (
      process.parent.executable == "/var/lib/dpkg/info/omi.postinst" and
      process.parent.command_line like "/bin/sh /var/lib/dpkg/info/omi.postinst configure *"
    ) or
    process.parent.command_line like "/bin/bash --init-file */.vscode-server/cli/servers/*/server/out/vs/workbench/*"
  )] as event0
  [process where event.type == "start" and event.action == "exec" and process.name in ("grep", "egrep", "fgrep", "pgrep") and
  not startswith~(process.command_line, event0.process.command_line) and
  process.command_line regex~ """.*\([a-z]{1,15}\|[a-z]{1,15}.*\).*""" and
  process.command_line like~ (
    "*|pem*", "*pem|*", "*|key*", "*key|*", "*|cred*", "*cred|*", "*|db*", "*db|*", "*|sqlite*", "*sqlite|*", "*|ssh*", "*ssh|*",
    "*|conf*", "*conf|*", "*|cnf*", "*cnf|*",  "*|ini*", "*ini|*", "*|secret*", "*secret|*", "*|token*", "*token|*",
    "*|auth*", "*auth|*", "*|passwd*",  "*passwd|*", "*|shadow*", "*shadow|*", "*|env*", "*env|*", "*|database*", "*database|*",
    "*|mysql*", "*mysql|*", "*|postgres*", "*postgres|*", "*|mongo*", "*mongo|*", "*|redis*", "*redis|*", "*|vault*", "*vault|*"
  )] as event1
  [process where event.type == "start" and event.action == "exec" and process.name in ("grep", "egrep", "fgrep", "pgrep") and
  not startswith~(process.command_line, event1.process.command_line) and
  process.command_line regex~ """.*\([a-z]{1,15}\|[a-z]{1,15}.*\).*""" and
  process.command_line like~ (
    "*|pem*", "*pem|*", "*|key*", "*key|*", "*|cred*", "*cred|*", "*|db*", "*db|*", "*|sqlite*", "*sqlite|*", "*|ssh*", "*ssh|*",
    "*|conf*", "*conf|*", "*|cnf*", "*cnf|*",  "*|ini*", "*ini|*", "*|secret*", "*secret|*", "*|token*", "*token|*",
    "*|auth*", "*auth|*", "*|passwd*",  "*passwd|*", "*|shadow*", "*shadow|*", "*|env*", "*env|*", "*|database*", "*database|*",
    "*|mysql*", "*mysql|*", "*|postgres*", "*postgres|*", "*|mongo*", "*mongo|*", "*|redis*", "*redis|*", "*|vault*", "*vault|*"
  )]
'''

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

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

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

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

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1082"
name = "System Information Discovery"
reference = "https://attack.mitre.org/techniques/T1082/"

[[threat.technique]]
id = "T1083"
name = "File and Directory Discovery"
reference = "https://attack.mitre.org/techniques/T1083/"


[threat.tactic]
id = "TA0007"
name = "Discovery"
reference = "https://attack.mitre.org/tactics/TA0007/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1074"
name = "Data Staged"
reference = "https://attack.mitre.org/techniques/T1074/"
[[threat.technique.subtechnique]]
id = "T1074.001"
name = "Local Data Staging"
reference = "https://attack.mitre.org/techniques/T1074/001/"


[[threat.technique]]
id = "T1119"
name = "Automated Collection"
reference = "https://attack.mitre.org/techniques/T1119/"


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

[internal]
min_endpoint_version = "8.4.0"

[metadata]
creation_date = "2020/02/18"
integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/08/31"

[rule]
author = ["Elastic"]
description = """
The Application Shim was created to allow for backward compatibility of software as the operating system codebase
changes over time. This Windows functionality has been abused by attackers to stealthily gain persistence and arbitrary
code execution in legitimate Windows processes.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
]
language = "eql"
license = "Elastic License v2"
name = "Potential Application Shimming via Sdbinst"
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 Potential Application Shimming via Sdbinst

Application shimming is a Windows feature designed to ensure software compatibility across different OS versions. However, attackers exploit this by using the `sdbinst.exe` tool to execute malicious code under the guise of legitimate processes, achieving persistence. The detection rule identifies suspicious invocations of `sdbinst.exe` by filtering out benign arguments, flagging potential misuse for further investigation.

### Possible investigation steps

- Review the process execution details to confirm the presence of sdbinst.exe with suspicious arguments that do not include the benign flags -m, -bg, or -mm.
- Investigate the parent process of sdbinst.exe to determine if it is a legitimate and expected process or if it is potentially malicious.
- Check the timeline of events around the execution of sdbinst.exe to identify any related or preceding suspicious activities, such as unusual file modifications or network connections.
- Analyze the user account associated with the execution of sdbinst.exe to verify if it is a legitimate user and if there are any signs of account compromise.
- Examine the system for any newly installed or modified application compatibility databases (.sdb files) that could be associated with the suspicious execution of sdbinst.exe.
- Correlate the alert with other security tools and logs, such as Microsoft Defender XDR or Sysmon, to gather additional context and confirm the presence of malicious activity.

### False positive analysis

- Legitimate software installations or updates may trigger sdbinst.exe with arguments that are not typically malicious. Users should verify the source and purpose of the software to determine if it is expected behavior.
- System administrators might use sdbinst.exe for deploying compatibility fixes across an organization. In such cases, document these activities and create exceptions for known administrative tasks.
- Some enterprise applications may use sdbinst.exe as part of their normal operation. Identify these applications and exclude their specific command-line arguments from triggering alerts.
- Scheduled tasks or scripts that include sdbinst.exe for maintenance purposes can be a source of false positives. Review these tasks and scripts, and whitelist them if they are part of routine operations.
- Regularly review and update the list of exceptions to ensure that only verified and necessary exclusions are maintained, minimizing the risk of overlooking genuine threats.

### Response and remediation

- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
- Terminate any suspicious processes associated with `sdbinst.exe` that do not match known legitimate usage patterns.
- Remove any unauthorized or suspicious application compatibility databases (.sdb files) that may have been installed using `sdbinst.exe`.
- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or persistence mechanisms.
- Review and restore any altered system configurations or registry settings to their default or secure state.
- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
- Implement enhanced monitoring and logging for `sdbinst.exe` executions across the network to detect and respond to future attempts at application shimming."""
risk_score = 21
rule_id = "fd4a992d-6130-4802-9ff8-829b89ae801f"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Windows Security Event Logs",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and process.name : "sdbinst.exe" and
  process.args : "?*" and
  not (process.args : "-m" and process.args : "-bg") and
  not process.args : (
    "-mm",
    "?:\\Windows\\appcompat\\cloudsdb\\apppatch.sdb",
    "\"?:\\Windows\\appcompat\\cloudsdb\\apppatch.sdb\"",
    "?:\\Program Files\\WindowsApps\\Microsoft.ApplicationCompatibilityEnhancements_*\\sdb\\sysMergeInboxStoreApp.sdb",
    "\"?:\\Program Files\\WindowsApps\\Microsoft.ApplicationCompatibilityEnhancements_*\\sdb\\sysMergeInboxStoreApp.sdb\"",
    "?:\\Program Files\\WindowsApps\\Microsoft.ApplicationCompatibilityEnhancements_*\\sdb\\msiMergeInboxStoreApp.sdb",
    "\"?:\\Program Files\\WindowsApps\\Microsoft.ApplicationCompatibilityEnhancements_*\\sdb\\msiMergeInboxStoreApp.sdb\"",
    "?:\\Program Files (x86)\\Citrix\\ICA Client\\CitrixWorkspaceLegacySWDA.sdb",
    "Citrix Workspace",
    "C:\\Program Files\\IIS Express\\iisexpressshim.sdb",
    "C:\\Program Files (x86)\\IIS Express\\iisexpressshim.sdb"
  )
'''

setup = """## Setup

This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

### Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

- [CrowdStrike](https://ela.st/crowdstrike-integration)
- [Microsoft Defender XDR](https://ela.st/m365-defender)
- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
"""


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1546"
name = "Event Triggered Execution"
reference = "https://attack.mitre.org/techniques/T1546/"
[[rule.threat.technique.subtechnique]]
id = "T1546.011"
name = "Application Shimming"
reference = "https://attack.mitre.org/techniques/T1546/011/"



[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1546"
name = "Event Triggered Execution"
reference = "https://attack.mitre.org/techniques/T1546/"
[[rule.threat.technique.subtechnique]]
id = "T1546.011"
name = "Application Shimming"
reference = "https://attack.mitre.org/techniques/T1546/011/"



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

[rule]
description = """
Identifies a url file download via WebDAV followed by the creation of executable content via WinINET. This may indicate
the successful exploitation of the vulnerability CVE-2024-21412. CVE-2024-21412 allows attackers to bypass the Microsoft
Defender SmartScreen security feature with booby-trapped Internet Shortcut files.
"""
id = "ad1cd9c5-f440-4f70-baa9-3f262d5ea414"
license = "Elastic License v2"
name = "Potential CVE-2024-21412 Exploitation"
os_list = ["windows"]
reference = [
    "https://www.trendmicro.com/en_us/research/24/b/cve202421412-water-hydra-targets-traders-with-windows-defender-s.html",
    "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21412",
]
version = "1.0.3"

query = '''
sequence with maxspan=1m
 [file where event.action == "creation" and process.name : ("explorer.exe", "winrar.exe", "7zfm.exe") and
  file.path : "?:\\Users\\*\\AppData\\Local\\Microsoft\\Windows\\INetCache\\IE\\*" and
  (file.extension : ("exe", "pif", "scr", "js", "vbs", "wsh", "hta", "cpl", "jse", "vbe", "bat", "cmd", "dll", "msi") or
   file.Ext.header_bytes : "4d5a*")]
 [file where process.name : "svchost.exe" and file.extension == "url" and
  file.path : "?:\\WINDOWS\\*\\TfsStore\\Tfs_DAV\\{*}.url"]
'''

actions = []
min_endpoint_version = "8.4.0"
[[optional_actions]]
action = "rollback"
field = "process.entity_id"
state = 0

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1566"
name = "Phishing"
reference = "https://attack.mitre.org/techniques/T1566/"
[[threat.technique.subtechnique]]
id = "T1566.001"
name = "Spearphishing Attachment"
reference = "https://attack.mitre.org/techniques/T1566/001/"



[threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1203"
name = "Exploitation for Client Execution"
reference = "https://attack.mitre.org/techniques/T1203/"


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

[internal]
min_endpoint_version = "8.4.0"

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

[rule]
author = ["Elastic"]
description = """
This rule looks for the usage of common data splitting utilities with specific arguments that indicate data splitting
for exfiltration on Linux systems. Data splitting is a technique used by adversaries to split data into smaller parts to
avoid detection and exfiltrate data.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Potential Data Splitting Detected"
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 Potential Data Splitting Detected

Data splitting utilities on Linux, such as `dd` and `split`, are typically used for managing large files by dividing them into smaller, more manageable parts. Adversaries exploit these tools to covertly exfiltrate data by splitting it into inconspicuous segments. The detection rule identifies suspicious use of these utilities by monitoring specific command-line arguments and excluding benign processes, thereby flagging potential exfiltration activities.

### Possible investigation steps

- Review the process details to confirm the use of data splitting utilities like 'dd', 'split', or 'rsplit' with suspicious arguments such as 'bs=*', 'if=*', '-b', or '--bytes*'.
- Examine the parent process name to ensure it is not a benign process like 'apport' or 'overlayroot', which are excluded in the rule.
- Investigate the source and destination paths specified in the process arguments to determine if they involve sensitive or unusual locations, excluding paths like '/tmp/nvim*', '/boot/*', or '/dev/urandom'.
- Check the user account associated with the process to assess if it has a history of legitimate use of these utilities or if it might be compromised.
- Analyze recent network activity from the host to identify any potential data exfiltration attempts, especially if the process involves external connections.
- Correlate this alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise.

### False positive analysis

- Processes related to system maintenance or updates, such as those initiated by the 'apport' or 'overlayroot' processes, may trigger false positives. Users can mitigate this by ensuring these parent processes are included in the exclusion list.
- Backup operations that use 'dd' or 'split' for legitimate data management tasks can be mistaken for exfiltration attempts. Exclude specific backup scripts or processes by adding their unique identifiers or arguments to the exclusion criteria.
- Development or testing environments where 'dd' or 'split' are used for creating test data or simulating data transfer can generate false alerts. Identify and exclude these environments by specifying their process names or argument patterns.
- Automated scripts that use 'dd' or 'split' for routine data processing tasks should be reviewed and, if benign, added to the exclusion list to prevent unnecessary alerts.
- Regular system operations involving '/dev/random', '/dev/urandom', or similar sources should be excluded, as these are common in non-malicious contexts and are already partially covered by the rule's exclusions.

### Response and remediation

- Immediately isolate the affected Linux system from the network to prevent further data exfiltration.
- Terminate any suspicious processes identified by the detection rule, specifically those involving the `dd`, `split`, or `rsplit` utilities with the flagged arguments.
- Conduct a thorough review of recent file access and modification logs to identify any unauthorized data handling or exfiltration attempts.
- Restore any potentially compromised data from secure backups, ensuring that the restored data is free from any malicious alterations.
- Implement stricter access controls and monitoring on sensitive data directories to prevent unauthorized access and manipulation.
- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected.
- Enhance monitoring and alerting for similar suspicious activities by integrating additional threat intelligence sources and refining detection capabilities."""
risk_score = 47
rule_id = "e302e6c3-448c-4243-8d9b-d41da70db582"
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: Exfiltration",
    "Data Source: Elastic Defend",
    "Data Source: Crowdstrike",
    "Data Source: SentinelOne",
    "Data Source: Elastic Endgame",
    "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 == "dd" and process.args like "bs=*" and process.args like "if=*") or
    (
      process.name in ("split", "rsplit") and
      (
        (process.args == "-b" or process.args like "--bytes*") or
        (process.args == "-C" or process.args like "--line-bytes*")
      )
    )
  ) and
  not (
    process.parent.name in ("apport", "overlayroot", "nessus-agent-module") or
    process.args like (
      "if=/tmp/nvim*", "if=/boot/*", "if=/dev/random", "if=/dev/urandom", "/dev/mapper/*",
      "if=*.iso", "of=/dev/stdout", "if=/dev/zero", "if=/dev/sda", "/proc/sys/kernel/*"
    ) or
    ?process.parent.args in ("/etc/init.d/apport", "/usr/bin/spectre-meltdown-checker")
  )
'''


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

[[rule.threat.technique]]
id = "T1030"
name = "Data Transfer Size Limits"
reference = "https://attack.mitre.org/techniques/T1030/"

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

[metadata]
creation_date = "2020/02/18"
integration = ["endpoint", "windows", "m365_defender", "system", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2026/05/04"

[transform]
[[transform.osquery]]
label = "Osquery - Retrieve DNS Cache"
query = "SELECT * FROM dns_cache"

[[transform.osquery]]
label = "Osquery - Retrieve All Services"
query = "SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"

[[transform.osquery]]
label = "Osquery - Retrieve Services Running on User Accounts"
query = """
SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE
NOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR
user_account == null)
"""

[[transform.osquery]]
label = "Osquery - Retrieve Service Unsigned Executables with Virustotal Link"
query = """
SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,
services.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =
authenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'
"""


[rule]
author = ["Elastic"]
description = """
The Filter Manager Control Program (fltMC.exe) binary may be abused by adversaries to unload a filter driver and evade
defenses.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-endpoint.events.process-*",
    "logs-m365_defender.event-*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Potential Evasion via Filter Manager"
note = """## Triage and analysis

### Investigating Potential Evasion via Filter Manager

A file system filter driver, or minifilter, is a specialized type of filter driver designed to intercept and modify I/O requests sent to a file system or another filter driver. Minifilters are used by a wide range of security software, including EDR, antivirus, backup agents, encryption products, etc.

Attackers may try to unload minifilters to avoid protections such as malware detection, file system monitoring, and behavior-based detections.

This rule identifies the attempt to unload a minifilter using the `fltmc.exe` command-line utility, a tool used to manage and query the filter drivers loaded on Windows systems.

> **Note**:
> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.

#### Possible investigation steps

- Identify the user account that performed the action and whether it should perform this kind of action.
- Examine the command line event to identify the target driver.
  - Identify the minifilter's role in the environment and if it is security-related. Microsoft provides a [list](https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/allocated-altitudes) of allocated altitudes that may provide more context, such as the manufacturer.
- Contact the account owner and confirm whether they are aware of this activity.
- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Examine the host for derived artifacts that indicate suspicious activities:
  - Observe and collect information about the following activities in the alert subject host:
    - Attempts to contact external domains and addresses.
      - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.
      - Examine the DNS cache for suspicious or anomalous entries.
        - $osquery_0
    - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.
    - Examine the host services for suspicious or anomalous entries.
      - $osquery_1
      - $osquery_2
      - $osquery_3

### False positive analysis

- This mechanism can be used legitimately. Analysts can dismiss the alert if the administrator is aware of the activity and there are justifications for the action.

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved host to prevent further post-compromise behavior.
- If the triage identified malware, search the environment for additional compromised hosts.
  - Implement temporary network rules, procedures, and segmentation to contain the malware.
  - Stop suspicious processes.
  - Immediately block the identified indicators of compromise (IoCs).
  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
- Remove and block malicious artifacts identified during triage.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""

setup = """## Setup

This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

### Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

- [Microsoft Defender XDR](https://ela.st/m365-defender)
- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
"""

risk_score = 47
rule_id = "06dceabf-adca-48af-ac79-ffdf4c3b1e9a"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Endgame",
    "Resources: Investigation Guide",
    "Data Source: Elastic Defend",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Windows Security Event Logs",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and
  process.name : "fltMC.exe" and process.args : "unload" and
  not process.parent.executable : 
                   ("?:\\Program Files (x86)\\ManageEngine\\UEMS_Agent\\bin\\DCFAService64.exe", 
                    "?:\\Windows\\SysWOW64\\msiexec.exe", 
                    "?:\\Program Files\\Bitdefender\\Endpoint Security\\installer\\installer.exe", 
                    "?:\\Program Files\\Bitdefender\\Endpoint Security\\EPSecurityService.exe", 
                    "?:\\Program Files\\Bitdefender\\Bitdefender Security\\productcfg.exe", 
                    "?:\\Program Files\\Bitdefender\\Bitdefender Security\\bdservicehost.exe", 
                    "?:\\Program Files\\Bitdefender\\EndpointSetupInformation\\{*}\\Installer.exe")
'''


[[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]
description = """
Identifies modification to the WinInet registry key by a process where the creating thread's stack contains frames
pointing to an unusual module.
"""
id = "c059ead9-d15e-4d13-86ee-ac5d8b9d6c34"
license = "Elastic License v2"
name = "Potential Module Stomping with Network Activity"
os_list = ["windows"]
version = "1.0.5"

query = '''
registry where event.action == "modification" and process.executable != null and registry.value == "CachePrefix" and
 registry.path : "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\*" and
 /* unusual stacks start module */
 process.thread.Ext.call_stack_summary regex """ntdll.dll\|kernelbase.dll\|wininet.dll\|ntdll.dll\|kernelbase.dll\|wininet.dll\|[a-z0-9\_\.\-]+\.dll""" and
 _arraysearch(process.thread.Ext.call_stack, $entry, ($entry.callsite_trailing_bytes : "?*" or $entry.protection == "RWX")) and
 not _arraysearch(process.thread.Ext.call_stack, $entry, $entry.symbol_info like "?:\\Program Files (x86)\\Steam\\steamapps\\common\\*") and
 not (process.executable == "C:\\Program Files\\KeyShot Studio\\bin\\keyshot.exe" and process.code_signature.subject_name == "KeyShot Inc." and process.code_signature.trusted == true)
'''

min_endpoint_version = "8.10.0"
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0
tree = true

[[optional_actions]]
action = "rollback"
field = "process.entity_id"
state = 0

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1055"
name = "Process Injection"
reference = "https://attack.mitre.org/techniques/T1055/"


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

[internal]
min_endpoint_version = "8.10.0"

[metadata]
creation_date = "2023/07/25"
integration = ["endpoint", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
This rule monitors for the potential edit of a suspicious file. In Linux, when editing a file through an editor, a
temporary .swp file is created. By monitoring for the creation of this .swp file, we can detect potential file edits of
suspicious files. The execution of this rule is not a clear sign of the file being edited, as just opening the file
through an editor will trigger this event. Attackers may alter any of the files added in this rule to establish
persistence, escalate privileges or perform reconnaisance on the system.
"""
from = "now-9m"
index = ["endgame-*", "logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*"]
language = "eql"
license = "Elastic License v2"
max_signals = 1
name = "Potential Suspicious File Edit"
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 Potential Suspicious File Edit

In Linux environments, text editors create temporary swap files (.swp) during file editing. Adversaries exploit this by editing critical system files to maintain persistence or escalate privileges. The detection rule identifies the creation of .swp files in sensitive directories, signaling potential unauthorized file edits, thus alerting analysts to investigate further.

### Possible investigation steps

- Review the alert details to identify the specific file path and name of the .swp file that triggered the alert, focusing on the directories and files listed in the query.
- Check the system logs and recent user activity to determine if there was any legitimate reason for editing the file, such as a scheduled maintenance or update.
- Investigate the user account associated with the file creation event to verify if the user has the necessary permissions and if their activity aligns with their role.
- Examine the contents of the original file (if accessible) and compare it with known baselines or backups to identify any unauthorized changes or anomalies.
- Look for other suspicious activities on the host, such as unusual login attempts, privilege escalation events, or the presence of other temporary files in sensitive directories.
- Assess the system for signs of persistence mechanisms or privilege escalation attempts, especially if the .swp file is associated with critical system files like /etc/shadow or /etc/passwd.

### False positive analysis

- Editing non-sensitive files in monitored directories can trigger alerts. Users can create exceptions for specific directories or files that are frequently edited by authorized personnel.
- System administrators performing routine maintenance or updates may inadvertently create .swp files in sensitive directories. Implementing a whitelist for known maintenance activities can reduce false positives.
- Automated scripts or applications that open files in monitored directories for legitimate purposes can cause alerts. Identifying and excluding these processes from monitoring can help manage false positives.
- Developers working on configuration files in their home directories might trigger alerts. Excluding specific user directories or known development environments can mitigate these occurrences.
- Regular system updates or package installations might create temporary .swp files. Monitoring these activities and correlating them with update schedules can help distinguish between legitimate and suspicious activities.

### Response and remediation

- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
- Terminate any suspicious processes associated with the creation of the .swp files in sensitive directories to halt any ongoing malicious activity.
- Restore the affected files from a known good backup to ensure system integrity and remove any unauthorized changes.
- Conduct a thorough review of user accounts and permissions, especially those with elevated privileges, to identify and revoke any unauthorized access.
- Implement additional monitoring on the affected system and similar environments to detect any further attempts to edit critical files.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
- Review and update system hardening measures, such as file permissions and access controls, to prevent similar incidents in the future."""
risk_score = 21
rule_id = "3728c08d-9b70-456b-b6b8-007c7d246128"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Privilege Escalation",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: SentinelOne",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
file where host.os.type == "linux" and event.action in ("creation", "file_create_event") and file.extension == "swp" and
file.path : (
  /* common interesting files and locations */
  "/etc/.shadow.swp", "/etc/.shadow-.swp", "/etc/.shadow~.swp", "/etc/.gshadow.swp", "/etc/.gshadow-.swp",
  "/etc/.passwd.swp", "/etc/.pwd.db.swp", "/etc/.master.passwd.swp", "/etc/.spwd.db.swp", "/etc/security/.opasswd.swp",
  "/etc/.environment.swp", "/etc/.profile.swp", "/etc/sudoers.d/.*.swp", "/etc/ld.so.conf.d/.*.swp",
  "/etc/init.d/.*.swp", "/etc/.rc.local.swp", "/etc/rc*.d/.*.swp", "/dev/shm/.*.swp", "/etc/update-motd.d/.*.swp",
  "/usr/lib/update-notifier/.*.swp",

  /* service, timer, want, socket and lock files */
  "/etc/systemd/system/.*.swp", "/usr/local/lib/systemd/system/.*.swp", "/lib/systemd/system/.*.swp",
  "/usr/lib/systemd/system/.*.swp","/home/*/.config/systemd/user/.*.swp", "/run/.*.swp", "/var/run/.*.swp/",

  /* profile and shell configuration files */
  "/home/*.profile.swp", "/home/*.bash_profile.swp", "/home/*.bash_login.swp", "/home/*.bashrc.swp", "/home/*.bash_logout.swp",
  "/home/*.zshrc.swp", "/home/*.zlogin.swp", "/home/*.tcshrc.swp", "/home/*.kshrc.swp", "/home/*.config.fish.swp",
  "/root/*.profile.swp", "/root/*.bash_profile.swp", "/root/*.bash_login.swp", "/root/*.bashrc.swp", "/root/*.bash_logout.swp",
  "/root/*.zshrc.swp", "/root/*.zlogin.swp", "/root/*.tcshrc.swp", "/root/*.kshrc.swp", "/root/*.config.fish.swp"
)
'''


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

[[rule.threat.technique]]
id = "T1037"
name = "Boot or Logon Initialization Scripts"
reference = "https://attack.mitre.org/techniques/T1037/"

[[rule.threat.technique.subtechnique]]
id = "T1037.004"
name = "RC Scripts"
reference = "https://attack.mitre.org/techniques/T1037/004/"

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

[[rule.threat.technique]]
id = "T1543"
name = "Create or Modify System Process"
reference = "https://attack.mitre.org/techniques/T1543/"

[[rule.threat.technique.subtechnique]]
id = "T1543.002"
name = "Systemd Service"
reference = "https://attack.mitre.org/techniques/T1543/002/"

[[rule.threat.technique]]
id = "T1546"
name = "Event Triggered Execution"
reference = "https://attack.mitre.org/techniques/T1546/"

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

[[rule.threat.technique]]
id = "T1574"
name = "Hijack Execution Flow"
reference = "https://attack.mitre.org/techniques/T1574/"

[[rule.threat.technique.subtechnique]]
id = "T1574.006"
name = "Dynamic Linker Hijacking"
reference = "https://attack.mitre.org/techniques/T1574/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 = "T1548"
name = "Abuse Elevation Control Mechanism"
reference = "https://attack.mitre.org/techniques/T1548/"

[[rule.threat.technique.subtechnique]]
id = "T1548.003"
name = "Sudo and Sudo Caching"
reference = "https://attack.mitre.org/techniques/T1548/003/"

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

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

[[rule.threat.technique]]
id = "T1003"
name = "OS Credential Dumping"
reference = "https://attack.mitre.org/techniques/T1003/"

[[rule.threat.technique.subtechnique]]
id = "T1003.008"
name = "/etc/passwd and /etc/shadow"
reference = "https://attack.mitre.org/techniques/T1003/008/"

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