Elastic rules: 08

[rule]
description = """
Identifies the call of Memory Windows APIs indirectly via a callback function. This may be the result of an evasion
attempt to hide the origin of the API call from the call stack such as unbacked memory region.
"""
id = "8154cddf-423f-4600-b20e-3ec55d972c7a"
license = "Elastic License v2"
name = " API via Callback from a Suspicious Stack"
os_list = ["windows"]
reference = [
    "https://www.elastic.co/security-labs/doubling-down-etw-callstacks",
    "https://klezvirus.github.io/posts/Callback-Hell/",
]
version = "1.0.1"

query = '''
api where
 process.Ext.api.name in ("VirtualProtect", "VirtualAlloc", "WriteProcessMemory", "VirtualProtectEx", "VirtualAllocEx", "SuspendThread") and
 _arraysearch(process.thread.Ext.call_stack, $entry, $entry.symbol_info : "C:\\Windows\\System32\\ntdll.dll!TpCallbackIndependent*") and
  process.thread.Ext.call_stack_summary like ("ntdll.dll|kernelbase.dll|*|ntdll.dll|kernelbase.dll|ntdll.dll|kernel32.dll|ntdll.dll",
                                              "ntdll.dll|kernelbase.dll|*|gdi32full.dll|kernelbase.dll|ntdll.dll|kernel32.dll|ntdll.dll",
                                              "ntdll.dll|kernelbase.dll|*|gdi32full.dll|user32.dll|ntdll.dll|kernel32.dll|ntdll.dll")
'''

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

[[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 = "2020/05/21"
integration = ["okta"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Detects when an administrator role is assigned to an Okta group. An adversary may attempt to assign administrator
privileges to an Okta group in order to assign additional permissions to compromised user accounts and maintain access
to their target organization.
"""
false_positives = [
    """
    Administrator roles may be assigned to Okta users by a Super Admin user. Verify that the behavior was expected.
    Exceptions can be added to this rule to filter expected behavior.
    """,
]
index = ["filebeat-*", "logs-okta*"]
language = "kuery"
license = "Elastic License v2"
name = "Administrator Privileges Assigned to an Okta Group"
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 Administrator Privileges Assigned to an Okta Group

Okta is a widely used identity management service that facilitates secure user authentication and access control. Administrator privileges in Okta allow users to manage settings and permissions, making them a target for adversaries seeking persistent access. Malicious actors may exploit these privileges by assigning them to groups, thereby extending elevated access to compromised accounts. The detection rule monitors system events for privilege grants to groups, flagging potential unauthorized privilege escalations.

### Possible investigation steps

- Review the event logs for entries with event.dataset:okta.system and event.action:group.privilege.grant to identify the specific group and administrator role assigned.
- Identify the user account that initiated the privilege grant action and verify if the account has a history of suspicious activity or if it has been compromised.
- Check the membership of the affected Okta group to determine which user accounts have gained elevated privileges and assess if any of these accounts are unauthorized or compromised.
- Investigate recent activities of the affected group members to identify any unusual or unauthorized actions that may indicate malicious intent.
- Review the organization's change management records to confirm if the privilege assignment was part of an approved change request or if it was unauthorized.
- If unauthorized activity is confirmed, initiate incident response procedures to revoke the unauthorized privileges and secure the affected accounts.

### False positive analysis

- Routine administrative tasks may trigger alerts when legitimate IT staff assign administrator roles to groups for maintenance or updates. To manage this, create exceptions for known IT personnel or scheduled maintenance windows.
- Organizational changes such as mergers or department restructuring might require temporary privilege escalations. Document these changes and adjust the detection rule to exclude these specific events during the transition period.
- Automated scripts or third-party integrations that manage group permissions could inadvertently trigger false positives. Identify these scripts and whitelist their actions within the monitoring system to prevent unnecessary alerts.
- Training or onboarding sessions where temporary admin access is granted to groups for demonstration purposes can cause alerts. Ensure these sessions are logged and recognized as non-threatening to avoid false positives.

### Response and remediation

- Immediately revoke the administrator privileges assigned to the Okta group to prevent further unauthorized access or privilege escalation.
- Conduct a thorough review of recent group membership changes and privilege assignments in Okta to identify any other unauthorized modifications.
- Isolate and investigate any user accounts that were part of the affected group to determine if they have been compromised.
- Reset passwords and enforce multi-factor authentication (MFA) for all accounts that were part of the affected group to secure them against further unauthorized access.
- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordinated response efforts.
- Implement additional monitoring on the affected group and related user accounts to detect any further suspicious activities.
- Review and update access control policies to ensure that only necessary groups and users have administrative privileges, reducing the risk of similar incidents in the future.

## Setup

The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://help.okta.com/en/prod/Content/Topics/Security/administrators-admin-comparison.htm",
    "https://developer.okta.com/docs/reference/api/system-log/",
    "https://developer.okta.com/docs/reference/api/event-types/",
    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
]
risk_score = 47
rule_id = "b8075894-0b62-46e5-977c-31275da34419"
severity = "medium"
tags = [
    "Use Case: Identity and Access Audit",
    "Data Source: Okta",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:okta.system and event.action:group.privilege.grant
'''


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

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

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1098.003"
name = "Additional Cloud Roles"
reference = "https://attack.mitre.org/techniques/T1098/003/"

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

[rule]
description = """
Identifies the execution of PowerShell script with keywords related to different Antimalware Scan Interface (AMSI)
bypasses. An adversary may attempt first to disable AMSI before executing further malicious powershell scripts to evade
detection.
"""
id = "ee4fbf59-c858-4a5d-bc74-e027926d7e2e"
license = "Elastic License v2"
name = "AMSI Bypass via PowerShell"
os_list = ["windows"]
reference = ["https://github.com/0xsyr0/Red-Team-Playbooks/blob/master/5-Installation/5-Installation.md"]
version = "1.0.6"

query = '''
api where process.Ext.api.name == "AmsiScanBuffer" and
 (process.name in~ ("powershell.exe") or process.Ext.api.parameters.app_name == "PowerShell") and
 (
  (process.Ext.api.parameters.buffer : ("*amsiContext*", "*amsiSession*", "*amsiInitFailed*", "*AmsiUtils*", "*AmsiInitialize*", "*AmsiScanString*") and
   process.Ext.api.parameters.buffer : "*.SetValue*" and process.Ext.api.parameters.buffer : "*.GetField*") or

  (process.Ext.api.parameters.buffer : "*[Ref].Assembly.GetType*System.Management.Automation.Amsi*" and
   process.Ext.api.parameters.buffer : "*.SetValue*" and process.Ext.api.parameters.buffer : "*.GetField*") or

  (process.Ext.api.parameters.buffer : "*[Ref].Assembly.GetTypes()*" and
   process.Ext.api.parameters.buffer : "*GetFields*" and process.Ext.api.parameters.buffer : ("*amsiIn*", "*iUtils*")) or

  (process.Ext.api.parameters.buffer : "*::AllocHGlobal*" and process.Ext.api.parameters.buffer : "*.NoRMALiZe*" and
   process.Ext.api.parameters.buffer : "*.SetValue*" and process.Ext.api.parameters.buffer : "*-replace*") or

  (process.Ext.api.parameters.buffer : "*System.Management.Automation.*" and process.Ext.api.parameters.buffer : "*.SetValue*" and
   process.Ext.api.parameters.buffer : ("*.GetField*NonPublic,Static*", "*FromBase64String*") and
    not (
      process.Ext.api.parameters.buffer : "*_outputEncoding*" and
      process.Ext.api.parameters.content_name in ("exec_wrapper.ps1", "exec_wrapper-async.ps1.ps1") and
      process.code_signature.subject_name : "Microsoft Windows" and process.code_signature.trusted == true
    )
  ) or

process.Ext.api.parameters.buffer :
                   ("*Invoke-AmsiBypass*",
                    "*AllocHGlobal*9076*",
                    "*cwBpAC4AZABsAGwA*",
                    "*41 6d 73 69 53 63 61 6e 42 75 66 66 65 72*",
                    "*5492868772801748688168747280728187173688878280688776828*")
  ) and
not process.parent.executable : "C:\\Program Files (x86)\\ManageSoft\\Tracker\\ndtrack.exe"
'''

min_endpoint_version = "8.16.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 = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[threat.technique.subtechnique]]
id = "T1059.001"
name = "PowerShell"
reference = "https://attack.mitre.org/techniques/T1059/001/"



[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"
[[threat.technique.subtechnique]]
id = "T1562.001"
name = "Disable or Modify Tools"
reference = "https://attack.mitre.org/techniques/T1562/001/"



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

[internal]
min_endpoint_version = "8.16.0"

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

[rule]
author = ["Elastic"]
description = """
Detects creation, modification, or deletion of AWS Bedrock Provisioned Model Throughput via the
CreateProvisionedModelThroughput, UpdateProvisionedModelThroughput, and DeleteProvisionedModelThroughput APIs.
Provisioned Throughput reserves dedicated, billed model capacity for Amazon Bedrock. An adversary who scales this
capacity up can drive large, unauthorized cost (cloud resource/bill hijacking), while deleting reserved throughput can
cause denial of service to production workloads that depend on that committed capacity. These control-plane changes
should be validated against approved capacity-planning and change-management processes.
"""
false_positives = [
    """
    Provisioned Throughput changes may be performed by platform, ML, or FinOps teams as part of capacity planning,
    scaling for production demand, or cost optimization. Infrastructure-as-code pipelines and automation roles may also
    create, update, or delete provisioned throughput during deployments. Verify that the user identity, user agent, and
    source IP correspond to known administrators or automation and that a corresponding change request exists. If known
    behavior is causing false positives, it can be exempted from the rule.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Bedrock Provisioned Model Throughput Tampering"
note = """## Triage and analysis

### Investigating AWS Bedrock Provisioned Model Throughput Tampering

Amazon Bedrock Provisioned Throughput reserves dedicated, billed model capacity for foundation models.
Because this capacity is committed and metered, adversaries can abuse it in two ways: scaling capacity up to
incur large, unauthorized cloud spend (resource/bill hijacking), or deleting reserved throughput to deny
service to production workloads that rely on committed capacity. This rule identifies
`CreateProvisionedModelThroughput`, `UpdateProvisionedModelThroughput`, and `DeleteProvisionedModelThroughput`
calls so responders can confirm whether the change was authorized.

#### Possible investigation steps

- **Identify the actor and context**
  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`,
    `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`.
  - Determine whether the identity is an approved administrator, ML/platform engineer, or automation role.
  - Confirm a corresponding change request or capacity-planning ticket exists.
- **Validate the request details**
  - Inspect `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements` for the model ID,
    commitment duration, and requested model units. Unusually large model-unit counts or long commitment
    terms on a Create/Update may indicate cost-driven abuse.
  - For `DeleteProvisionedModelThroughput`, identify which provisioned model was removed and whether any
    production workload depended on it.
- **Correlate activity**
  - Review other Bedrock control-plane actions (e.g., model invocation logging changes, guardrail changes)
    and IAM/STS activity from the same identity around the same time.
  - Check `cloud.account.id` and `cloud.region` for whether the activity occurred in an expected account/region.

### False positive analysis

- **Capacity planning**: Platform, ML, or FinOps teams may legitimately create, update, or delete provisioned
  throughput. Validate against change tickets and standard capacity-management procedures.
- **Automation**: IaC or deployment pipelines may manage provisioned throughput on bootstrap or teardown.
  Confirm the source IP and ARN match expected automation infrastructure.

### Response and remediation

- If unauthorized, immediately disable the offending access key or role and revert the change (delete
  unauthorized provisioned throughput, or recreate deleted reserved capacity required by production).
- Review billing and Cost Explorer for unexpected Bedrock provisioned-throughput charges.
- Audit the actor's recent activity and rotate credentials if compromise is suspected.
- Restrict `bedrock:CreateProvisionedModelThroughput`, `bedrock:UpdateProvisionedModelThroughput`, and
  `bedrock:DeleteProvisionedModelThroughput` to a small set of administrative roles and enforce approval
  workflows and budget alarms.

### Additional information

- **[Amazon Bedrock Provisioned Throughput](https://docs.aws.amazon.com/bedrock/latest/userguide/prov-throughput.html)**
"""
references = [
    "https://docs.aws.amazon.com/bedrock/latest/userguide/prov-throughput.html",
    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateProvisionedModelThroughput.html",
    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteProvisionedModelThroughput.html",
    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_UpdateProvisionedModelThroughput.html"
]
risk_score = 47
rule_id = "42b5e06d-b297-4286-a004-ae0da92c5b81"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: LLM",
    "Data Source: AWS",
    "Data Source: AWS CloudTrail",
    "Data Source: Amazon Web Services",
    "Data Source: Amazon Bedrock",
    "Use Case: Threat Detection",
    "Resources: Investigation Guide",
    "Tactic: Impact",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail" and
    event.provider: "bedrock.amazonaws.com" and
    event.action: (
        "CreateProvisionedModelThroughput" or
        "UpdateProvisionedModelThroughput" or
        "DeleteProvisionedModelThroughput"
    ) and
    event.outcome: "success"
'''


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

[[rule.threat.technique]]
id = "T1496"
name = "Resource Hijacking"
reference = "https://attack.mitre.org/techniques/T1496/"

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

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

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

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

[rule]
author = ["Elastic", "Austin Songer"]
description = """
Identifies attempts to delete AWS Config resources. AWS Config provides continuous visibility into resource
configuration changes and compliance posture across an account. Deleting Config components can significantly reduce
security visibility and auditability. Adversaries may delete or disable Config resources to evade detection, hide prior
activity, or weaken governance controls before or after other malicious actions.
"""
false_positives = [
    """
    Deletion of AWS Config resources may occur during legitimate account restructuring, environment teardown, or changes
    to compliance tooling. Centralized security teams or approved automation may also delete and recreate Config
    components as part of controlled workflows. Confirm that the action aligns with approved change management and was
    performed by an expected principal.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Config Resource Deletion"
note = """## Triage and analysis

### Investigating AWS Config Resource Deletion

AWS Config records configuration changes, relationships, and compliance status for AWS resources over time.
Deleting Config components such as recorders, delivery channels, rules, or conformance packs disrupts
security monitoring, compliance enforcement, and forensic visibility. This behavior is uncommon outside of
planned infrastructure changes and should be treated as high-risk when unexpected. This rule detects successful deletion of AWS Config resources.

### Possible investigation steps

**Identify the actor**
- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who initiated the deletion.
- Confirm whether this principal typically manages AWS Config or centralized security tooling.
- Check `user_agent.original` to determine whether the action was performed via console, CLI, SDK, or automation.

**Determine what was deleted**
- Inspect `event.action` and `aws.cloudtrail.request_parameters` to identify which Config component was removed
  (e.g., configuration recorder, delivery channel, rule, aggregator, or conformance pack).
- Assess whether the deleted resource was account-scoped or organization-wide. Used for compliance reporting, guardrails, or security monitoring.
- Identify the affected regions and accounts using `cloud.region` and `cloud.account.id`.

**Reconstruct timing and intent**
- Use `@timestamp` to correlate the deletion with:
  - IAM changes (role updates, policy modifications, STS activity).
  - Other monitoring disruptions (CloudTrail, GuardDuty, Security Hub).
  - Destructive or high-impact actions occurring shortly before or after.
- Compare the timing against approved maintenance windows or infrastructure changes.

**Correlate with broader activity**
- Pivot in CloudTrail on the same principal or access key to identify:
  - Additional attempts to disable logging or security controls.
  - Resource deletions or configuration weakening across services.
- Evaluate whether the deletion appears isolated or part of a broader evasion sequence.

**Validate intent with stakeholders**
- Confirm with security, cloud platform, or compliance teams whether the deletion was planned and approved.
- Verify whether replacement Config resources were created shortly after, or whether monitoring remains disabled.

### False positive analysis

- **Planned environment changes**
  - Non-production account teardown, environment consolidation, or compliance tool migrations may involve
    deletion of Config resources.

- **Authorized security automation**
  - Approved automation or security tooling may delete and recreate Config components during setup or remediation.
  - Tune exceptions carefully using specific principals or automation roles rather than broad exclusions.

### Response and remediation

- **Contain and restore visibility**
  - If unauthorized, immediately re-enable AWS Config components, including recorders and delivery channels.
  - Validate that historical configuration data and compliance reporting resume as expected.

- **Investigate scope and impact**
  - Determine how long Config visibility was impaired and what activity may have occurred during that window.
  - Review other monitoring gaps (e.g., CloudTrail or GuardDuty changes) for coordinated evasion.

- **Credential and access review**
  - Rotate or disable credentials associated with the deleting principal if compromise is suspected.
  - Review IAM permissions to ensure only a minimal, well-defined set of roles can manage AWS Config.

- **Hardening and prevention**
  - Use SCPs or IAM conditions to restrict deletion of Config resources in production and security accounts.
  - Implement AWS Config rules or Security Hub controls to alert when Config is disabled or degraded.
  - Document and formalize change procedures for governance tooling.

### 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)** 
- **[AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)**
"""
references = [
    "https://docs.aws.amazon.com/config/latest/developerguide/how-does-config-work.html",
    "https://docs.aws.amazon.com/config/latest/APIReference/API_Operations.html",
]
risk_score = 47
rule_id = "7024e2a0-315d-4334-bb1a-552d604f27bc"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS Config",
    "Tactic: Defense Evasion",
    "Rule Type: Custom Query (KQL)",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: aws.cloudtrail 
    and event.provider: config.amazonaws.com 
    and event.outcome: success
    and event.action: (DeleteConfigRule or DeleteOrganizationConfigRule or DeleteConfigurationAggregator or
    DeleteConfigurationRecorder or DeleteConformancePack or DeleteOrganizationConformancePack or
    DeleteDeliveryChannel or DeleteRemediationConfiguration or DeleteRetentionConfiguration)
    and not aws.cloudtrail.user_identity.invoked_by: (securityhub.amazonaws.com or fms.amazonaws.com or controltower.amazonaws.com or config-conforms.amazonaws.com)
    and not user_agent.original: (*Pulumi* or *Terraform*)
'''


[[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.technique.subtechnique]]
id = "T1562.008"
name = "Disable or Modify Cloud Logs"
reference = "https://attack.mitre.org/techniques/T1562/008/"



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

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

[metadata]
bypass_bbr_timing = true
creation_date = "2024/07/24"
integration = ["aws"]
maturity = "production"
updated_date = "2026/08/05"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Identifies when an EC2 instance interacts with the AWS IAM service via an assumed role. This is uncommon behavior and
could indicate an attacker using compromised credentials to further exploit an environment. For example, an assumed role
could be used to create new users for persistence or add permissions for privilege escalation. An EC2 instance assumes a
role using their EC2 ID as the session name. This rule looks for the pattern "i-" which is the beginning pattern for
assumed role sessions started by an EC2 instance. This is a [building
block](https://www.elastic.co/guide/en/security/current/building-block-rule.html) rule and does not generate alerts on
its own. It is meant to be used for correlation with other rules to detect suspicious activity.
"""
false_positives = [
    """
    Administrators may use EC2 instances to interact with IAM services as part of an automation workflow, ensure
    validity of the triggered event and include exceptions where necessary.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "eql"
license = "Elastic License v2"
name = "AWS EC2 Instance Interaction with IAM Service"
references = ["https://redcanary.com/blog/aws-sts/"]
risk_score = 21
rule_id = "a44bcb58-5109-4870-a7c6-11f5fe7dd4b1"
severity = "low"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS EC2",
    "Service: AWS IAM",
    "Tactic: Persistence",
    "Tactic: Privilege Escalation",
    "Rule Type: BBR",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
any where event.dataset == "aws.cloudtrail"
    and event.provider == "iam.amazonaws.com"
    and aws.cloudtrail.user_identity.type == "AssumedRole"
    and stringContains(user.id, ":i-")
    and (
            startsWith(event.action, "Update")
            or startsWith(event.action, "Attach")
            or startsWith(event.action, "Detach")
            or startsWith(event.action, "Create")
            or startsWith(event.action, "Delete")
            or startsWith(event.action, "Add")
            or startsWith(event.action, "Remove")
            or startsWith(event.action, "Put")
            or startsWith(event.action, "Tag")
    )
    and not user_agent.original like~ ("*Terraform*", "*Pulumi*", "*Ansible*")
'''

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

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


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

[[rule.threat.technique.subtechnique]]
id = "T1098.003"
name = "Additional Cloud Roles"
reference = "https://attack.mitre.org/techniques/T1098/003/"



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

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

[rule]
description = """
Detects when the tc (traffic control) binary is utilized to set a BPF (Berkeley Packet Filter) on a network interface.
Tc is used to configure Traffic Control in the Linux kernel. It can shape, schedule, police and drop traffic. A threat
actor can utilize tc to set a bpf filter on an interface for the purpose of manipulating the incoming traffic. This
technique is not at all common and should indicate abnormal, suspicious or malicious activity.
"""
id = "bde36476-0c2c-40df-b3b1-941b0b31e444"
license = "Elastic License v2"
name = "BPF Filter Applied using Traffic Control"
os_list = ["linux"]
version = "1.0.1"

query = '''
process where event.type == "start" and event.action == "exec" and process.name == "tc" and
process.args == "filter" and process.args == "add" and process.args == "bpf" and
not process.parent.executable == "/usr/sbin/libvirtd"
'''

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

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

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



[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"
[[threat.technique.subtechnique]]
id = "T1562.001"
name = "Disable or Modify Tools"
reference = "https://attack.mitre.org/techniques/T1562/001/"



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

[internal]
min_endpoint_version = "7.15.0"

[rule]
description = """
This rule monitors for egress network connections from processes that are executed from an RPM package parent. Attackers
can backdoor an RPM package to establish initial access, or install a malicious RPM package to maintain persistence.
"""
id = "d20cd4ba-ff65-4e1c-8012-4241d449b16b"
license = "Elastic License v2"
name = "Egress Network Connection from RPM Package"
os_list = ["linux"]
version = "1.0.13"

query = '''
sequence with maxspan=3s
  [process where event.type == "start" and event.action == "exec" and
   process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
   process.parent.args : "/var/tmp/rpm-tmp.*" and not (
     (process.name == "curl" and process.command_line like ("*.microsoft.com/api/report*", "*check.percona.com*")) or
     process.executable in ("/sbin/runuser", "/usr/sbin/runuser") or
     process.working_directory like~ (
       "/builds/packages/naudit-repos", "/disco_flowlytics/docker/overlay2/*", "/builddir/build/BUILD/librdkafka-*/mklove/deps/src/libzstd"
     ) or
     process.args : ("/usr/local/cpanel/3rdparty/wp-toolkit/*", "/usr/bin/rpmkeys") or
     (process.executable == "/bin/sudo" and process.args in (
       "https://global.endpoint.security.micro",
       "https://global.endpoint.security.micros"
       )
     ) or
     (process.name == "curl" and process.args == "sudo" and process.args == "mdatp" and process.args == "--cacert") or
     process.command_line like "runuser -u mdatp*" or
     process.name == "sudo"
   )
  ] by process.entity_id
  [network where event.type == "start" and event.action == "connection_attempted" and not (
     destination.ip == null or
     destination.ip == "0.0.0.0" or
     cidrmatch(
       destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29",
       "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24",
       "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10",
       "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10",
       "FF00::/8", "172.31.0.0/16"
       ) or
      process.executable in (
      "/opt/cisco/amp/bin/ampinsthelper", "/usr/libexec/platform-python", "/sbin/update-pciids",
      "/etc/nginx/ea-nginx/config-scripts/global/config-scripts-global-cloudflare",
      "/opt/kerio/GFIAgent/GFIAgentInstaller", "/usr/share/centrifydc/libexec/adinfo",
      "/opt/teleport/system/bin/tsh"
      ) or
      process.executable like "/usr/local/cpanel/3rdparty/perl/*/bin/perl"
    )
  ] by process.parent.entity_id
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1195"
name = "Supply Chain Compromise"
reference = "https://attack.mitre.org/techniques/T1195/"
[[threat.technique.subtechnique]]
id = "T1195.002"
name = "Compromise Software Supply Chain"
reference = "https://attack.mitre.org/techniques/T1195/002/"



[threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1543"
name = "Create or Modify System Process"
reference = "https://attack.mitre.org/techniques/T1543/"

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


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


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


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

[internal]
min_endpoint_version = "8.6.0"

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

[rule]
author = ["Elastic"]
description = """
Identifies when a user is added as an owner for an Azure application. An adversary may add a user account as an owner
for an Azure application in order to grant additional permissions and modify the application's configuration using
another account.
"""
from = "now-9m"
index = ["logs-azure.auditlogs-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID User Added as Registered Application Owner"
note = """## Triage and analysis

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

### Investigating Entra ID User Added as Registered Application Owner

Azure applications often require specific permissions for functionality, managed by assigning user roles. An adversary might exploit this by adding themselves or a compromised account as an owner, gaining elevated privileges to alter configurations or access sensitive data. The detection rule monitors audit logs for successful operations where a user is added as an application owner, flagging potential unauthorized privilege escalations.

### Possible investigation steps

- Review the Azure audit logs to confirm the operation by filtering for event.dataset:azure.auditlogs and azure.auditlogs.operation_name:"Add owner to application" with a successful outcome.
- Identify the user account that was added as an owner and the account that performed the operation to determine if they are legitimate or potentially compromised.
- Check the history of activities associated with both the added owner and the account that performed the operation to identify any suspicious behavior or patterns.
- Verify the application's current configuration and permissions to assess any changes made after the new owner was added.
- Contact the legitimate owner or administrator of the Azure application to confirm whether the addition of the new owner was authorized.
- Investigate any recent changes in the organization's user access policies or roles that might explain the addition of a new owner.

### False positive analysis

- Routine administrative actions: Regular maintenance or updates by IT staff may involve adding users as application owners. To manage this, create a list of authorized personnel and exclude their actions from triggering alerts.
- Automated processes: Some applications may have automated scripts or services that add users as owners for operational purposes. Identify these processes and configure exceptions for their activities.
- Organizational changes: During mergers or restructuring, there may be legitimate reasons for adding multiple users as application owners. Temporarily adjust the rule to accommodate these changes and review the audit logs manually.
- Testing and development: In development environments, users may be added as owners for testing purposes. Exclude these environments from the rule or set up a separate monitoring policy with adjusted thresholds.

### Response and remediation

- Immediately revoke the added user's owner permissions from the Azure application to prevent further unauthorized access or configuration changes.
- Conduct a thorough review of recent activity logs for the affected application to identify any unauthorized changes or data access that may have occurred since the user was added as an owner.
- Reset credentials and enforce multi-factor authentication for the compromised or suspicious account to prevent further misuse.
- Notify the security team and relevant stakeholders about the incident for awareness and potential escalation if further investigation reveals broader compromise.
- Implement additional monitoring on the affected application and related accounts to detect any further unauthorized access attempts or privilege escalations.
- Review and update access control policies to ensure that only authorized personnel can modify application ownership, and consider implementing stricter approval processes for such changes.
- Document the incident, including actions taken and lessons learned, to improve response strategies and prevent recurrence.

## Setup

The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
risk_score = 21
rule_id = "774f5e28-7b75-4a58-b94e-41bf060fdd86"
severity = "low"
tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Persistence", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"

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


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

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

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

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

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

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

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

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

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

[metadata]
creation_date = "2023/03/07"
integration = ["google_workspace"]
maturity = "production"
min_stack_comments = "Changing min stack to 9.3.0, the latest minimum supported version for 9.X releases."
min_stack_version = "9.3.0"
updated_date = "2026/07/20"

[rule]
author = ["Elastic"]
description = """
Detects when a user copies a Google document, spreadsheet, form, or script from an external Drive into their Workspace
Drive and shortly after authorizes a custom Google OAuth application. Adversaries may send spearphishing links with a
/copy URI parameter so the victim replicates a malicious object locally. Container-bound Apps Script can then execute on
open and prompt the user for OAuth consent, granting the attacker's application access to Workspace data.
"""
false_positives = [
    """
    Google Workspace users typically share Drive resources with a shareable link where parameters are edited to indicate
    when it is viewable or editable by the intended recipient. It is uncommon for a user in an organization to manually
    copy a Drive object from an external drive to their corporate drive. This may happen where users find a useful
    spreadsheet in a public drive, for example, and replicate it to their Drive. It is uncommon for the copied object to
    execute a container-bound script either unless the user was intentionally aware, suggesting the object uses
    container-bound scripts to accomplish a legitimate task.
    """,
]
from = "now-130m"
index = ["logs-google_workspace.*"]
interval = "10m"
language = "eql"
license = "Elastic License v2"
name = "Google Workspace Object Copied from External Drive with App Consent"
note = """## Triage and analysis

### Investigating Google Workspace Object Copied from External Drive with App Consent

Google Workspace users can receive Drive links with URI parameters such as `view`, `edit`, or `copy`. A `copy` link lets
the recipient replicate the object into their own Drive. Documents, spreadsheets, forms, and Apps Script projects can
include container-bound scripts that run when the object is opened. Copying alone does not produce an OAuth event; the
user must open the copied object (or trigger an installable `onOpen` handler) before Apps Script can prompt for consent.

This rule correlates two events for the same `source.user.email` within `maxspan=3m` using `@timestamp` (Google event
time). When a user copies a Google document, spreadsheet, form, or script from an external Drive into their Workspace
Drive and shortly after authorizes a custom Google OAuth application.

### Possible investigation steps

- Identify the affected user from `source.user.email` or `user.email` in the alert. Note `source.ip` and compare
  `@timestamp` (event time).
- Drive copy event (`google_workspace.drive`):
  - Review `file.name`, `file.id`, and `google_workspace.drive.file.type` to identify what was copied.
  - For deeper review, pivot on `file.id` or `file.name` in Drive audit logs and Admin console Drive investigation.
- OAuth authorize event (`google_workspace.token`):
  - Review `google_workspace.token.app_name` and `google_workspace.token.client.id` to identify the application.
  - Review granted scopes in `google_workspace.token.scope.value` to determine which services the token can access
    (for example Drive, Gmail, or Calendar scopes beyond identity).
  - Review `google_workspace.token.client.type` and any `user.domain` context if present.
- Determine whether the activity is expected:
  - Contact the user to confirm they intentionally copied an external template and authorized the application.
  - If timing or `source.ip` is unusual for the user, treat as higher priority until validated.
- Search Kibana for related activity:
  - Determine whether other users copied the same external object:
    ```
    data_stream.dataset: "google_workspace.drive" and event.action: "copy" and google_workspace.drive.copy_type: "external" and file.name: "<FILE_NAME>"
    ```
  - Correlate with sign-in activity around the same window:
    ```
    data_stream.dataset: "google_workspace.login" and user.email: "<USER_EMAIL>"
    ```
  - Scope for other OAuth grants to the same client across the tenant:
    ```
    data_stream.dataset: "google_workspace.token" and event.action: "authorize" and google_workspace.token.client.id: "<CLIENT_ID>"
    ```
- If a container-bound script is suspected, locate the copied object in the user's Drive and review Apps Script code
  for exfiltration, token harvesting, or persistence logic. Remove the object from affected users' Drives.

### False positive analysis

- Users may legitimately copy public templates (spreadsheets, forms, or documents) from external drives for personal or
  business use; OAuth consent afterward may still be benign if the embedded script is intentional (for example a known
  add-on or vendor workflow).
- OAuth consent does not always follow copy immediately; opening the object later can separate the two actions beyond
  `maxspan=3m`, which would prevent a match even when activity is related.

### Response and remediation

- Initiate the incident response process based on triage findings.
- If the copy or OAuth grant is not clearly authorized, revoke the application's access for the affected user under
  Security > Access and data control > API controls (or remove the user token via admin OAuth reports).
- Remove malicious copied objects from affected users' Drives and report abusive OAuth clients to Google if appropriate.
- If the user account is suspected compromised, reset credentials, revoke active sessions, and review all OAuth grants
  for that user.
- Review activity performed with the authorized token based on scopes in `google_workspace.token.scope.value`.
- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
    - Identify the account role in the cloud environment.
    - Assess the criticality of affected services and servers.
    - Work with your IT team to identify and minimize the impact on users.
    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
    - Identify any regulatory or legal ramifications related to this activity.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.
- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google.
- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).

## Setup

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

### Important Information Regarding Google Workspace Event Lag Times
- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs.
- This rule is configured to run every 10 minutes with a lookback time of 130 minutes and uses `timestamp_override: event.ingested` so delayed ingest does not drop events from the execution window. Sequence correlation and `maxspan` still use `@timestamp` event time.
- Drive and token audit events may arrive on different schedules; the token integration polls Google's API on a longer default interval. To reduce false negatives, consider reducing the poll interval for both Drive and token data sources.
- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m).
"""
references = [
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two",
    "https://developers.google.com/apps-script/guides/bound",
    "https://developers.google.com/identity/protocols/oauth2",
    "https://support.google.com/a/users/answer/13004165#share_make_a_copy_links",
]
risk_score = 73
rule_id = "f33e68a4-bd19-11ed-b02f-f661ea17fbcc"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: Google Workspace",
    "Tactic: Initial Access",
    "Tactic: Execution",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
sequence by source.user.email with maxspan=3m
[file where data_stream.dataset == "google_workspace.drive" and event.action == "copy" and

    /* Should only match if the object lives in a Drive that is external to the user's GWS organization */
    google_workspace.drive.owner_is_team_drive == false and google_workspace.drive.copy_type == "external" and

    /* Google Script, Forms, Sheets and Document can have container-bound scripts */
    google_workspace.drive.file.type: ("script", "form", "spreadsheet", "document")]

[any where data_stream.dataset == "google_workspace.token" and event.action == "authorize" and

    /* Ensures application ID references custom app in Google Workspace and not GCP */
    google_workspace.token.client.id : "*apps.googleusercontent.com"]
'''


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



[rule.threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1204"
name = "User Execution"
reference = "https://attack.mitre.org/techniques/T1204/"
[[rule.threat.technique.subtechnique]]
id = "T1204.001"
name = "Malicious Link"
reference = "https://attack.mitre.org/techniques/T1204/001/"



[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"
[[rule.threat.technique.subtechnique]]
id = "T1098.001"
name = "Additional Cloud Credentials"
reference = "https://attack.mitre.org/techniques/T1098/001/"



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

[rule.investigation_fields]
field_names = ["user.name", "user.email", "source.ip"]

[metadata]
creation_date = "2023/10/16"
integration = ["problemchild", "endpoint"]
maturity = "production"
updated_date = "2026/07/27"
min_stack_version = "9.4.0"
min_stack_comments = "Use EA (Entity Analytics) fields"

[rule]
anomaly_threshold = 75
author = ["Elastic"]
description = """
A machine learning job combination has identified a parent process with one or more suspicious Windows processes that
exhibit unusually high malicious probability scores. These process(es) have been classified as malicious in several
ways. The process(es) were predicted to be malicious by the ProblemChild supervised ML model. If the anomaly contains a
cluster of suspicious processes, each process has the same parent process name, and the aggregate score of the event
cluster was calculated to be unusually high by an unsupervised ML model. Such a cluster often contains suspicious or
malicious activity, possibly involving LOLbins, that may be resistant to detection using conventional search rules.
"""
from = "now-45m"
interval = "15m"
license = "Elastic License v2"
machine_learning_job_id = "problem_child_high_sum_by_parent_ea"
name = "Parent Process Detected with Suspicious Windows Process(es)"
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 Parent Process Detected with Suspicious Windows Process(es)

In Windows environments, processes are often spawned by parent processes, forming a hierarchy. Adversaries exploit this by using legitimate processes to launch malicious ones, often leveraging Living off the Land Binaries (LOLBins) to evade detection. The detection rule employs machine learning to identify clusters of processes with high malicious probability, focusing on those sharing a common parent process. This approach helps uncover stealthy attacks that traditional methods might miss, enhancing defense against tactics like masquerading.

### Possible investigation steps

- Review the parent process name associated with the suspicious process cluster to identify if it is a known legitimate process or a potential masquerading attempt.
- Examine the command line arguments and execution context of the suspicious processes to identify any use of LOLBins or unusual patterns that could indicate malicious activity.
- Check the process creation timestamps and correlate them with any known events or user activities to determine if the process execution aligns with expected behavior.
- Investigate the network activity of the suspicious processes to identify any unusual outbound connections or data exfiltration attempts.
- Analyze the user account context under which the suspicious processes were executed to determine if there is any indication of compromised credentials or privilege escalation.
- Cross-reference the detected processes with threat intelligence sources to identify any known indicators of compromise or related threat actor activity.

### False positive analysis

- Legitimate administrative tools may trigger false positives if they frequently spawn processes that resemble malicious activity. Users can create exceptions for known safe tools by whitelisting their parent process names.
- Software updates or installations often generate clusters of processes that might be flagged as suspicious. Users should monitor these activities and exclude them if they are verified as legitimate.
- Automated scripts or batch jobs that run regularly and spawn multiple processes can be mistaken for malicious clusters. Identifying these scripts and excluding their parent processes can reduce false positives.
- Security software or monitoring tools that perform regular scans or updates might mimic malicious behavior. Users should ensure these tools are recognized and excluded from the rule's scope.
- Custom business applications that are not widely recognized might be flagged. Users should document and exclude these applications if they are confirmed to be safe and necessary for operations.

### Response and remediation

- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any ongoing malicious activity.
- Terminate the suspicious processes identified by the alert to stop any malicious actions they may be performing.
- Conduct a thorough review of the parent process and its associated binaries to ensure they have not been tampered with or replaced by malicious versions.
- Restore any affected files or system components from a known good backup to ensure system integrity and functionality.
- Update and patch the system to close any vulnerabilities that may have been exploited by the adversary, focusing on those related to LOLBins and masquerading techniques.
- Monitor the system and network for any signs of re-infection or related suspicious activity, using enhanced logging and alerting mechanisms.
- 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/guide/en/security/current/prebuilt-ml-jobs.html",
    "https://docs.elastic.co/en/integrations/problemchild",
    "https://www.elastic.co/security-labs/detecting-living-off-the-land-attacks-with-new-elastic-integration",
]
risk_score = 21
rule_id = "f5d9d36d-7c30-4cdb-a856-9f653c13d4e0"
setup = """## Setup

The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat.

### LotL Attack Detection Setup
The LotL Attack Detection integration detects living-off-the-land activity in Windows process events.

#### Prerequisite Requirements:
- Fleet is required for LotL Attack Detection.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
- Windows process events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) integration or Winlogbeat(https://www.elastic.co/guide/en/beats/winlogbeat/current/_winlogbeat_overview.html).
- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
- To set up and run Winlogbeat, follow [this](https://www.elastic.co/guide/en/beats/winlogbeat/current/winlogbeat-installation-configuration.html) guide.

#### The following steps should be executed to install assets associated with the LotL Attack Detection integration:
- Go to the Kibana homepage. Under Management, click Integrations.
- In the query bar, search for Living off the Land Attack Detection and select the integration to see more details about it.
- Follow the instructions under the **Installation** section.
- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
"""
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Data Source: Elastic Defend",
    "Data Source: Elastic Endgame",
    "Use Case: Living off the Land Attack Detection",
    "Rule Type: ML",
    "Rule Type: Machine Learning",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
type = "machine_learning"
[[rule.threat]]
framework = "MITRE ATT&CK"

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

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

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

[metadata]
creation_date = "2026/04/29"
integration = ["auditd_manager"]
maturity = "production"
updated_date = "2026/04/29"

[rule]
author = ["Elastic"]
description = """
Correlates a burst of non-root AF_ALG-class "socket", "splice", or "bound-socket" telemetry with a subsequent process execution
where effective user is root but the login user remains non-root. This sequence matches common post-exploitation chains
for Copy Fail (CVE-2026-31431) style abuse where AF_ALG and "splice" primitives precede executing a corrupted setuid
binary from cache.
"""
false_positives = [
    """
    Legitimate AF_ALG usage from unprivileged users is uncommon, but some kernel crypto tests, IPsec helpers, disk
    encryption tooling, HSM integrations, or approved security research systems may exercise this interface. Verify the
    process, user, and host role before adding an exception.
    """,
]
from = "now-6m"
index = ["auditbeat-*", "logs-auditd_manager.auditd-*"]
language = "eql"
license = "Elastic License v2"
name = "Potential Copy Fail (CVE-2026-31431) Exploitation via AF_ALG Socket"
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 Copy Fail (CVE-2026-31431) Exploitation via AF_ALG Socket

Copy Fail (CVE-2026-31431) abuses the Linux kernel `authencesn` AEAD path through AF_ALG and `splice()` to write four controlled bytes into the page cache of a readable file. Public exploitation targets setuid-root binaries such as `/usr/bin/su`, then executes the corrupted in-memory copy to gain root. The file on disk is not modified, so traditional on-disk integrity checks may miss the activity.

This sequence rule requires many (`runs=10`) non-root `splice` or AF_ALG-related `socket` events (`auditd.data.a0 == "26"`)
within 60 seconds, followed by an `executed` event where `user.effective.id` is root while `user.id` is still non-root.
That ordering aligns with abusing AF_ALG/`splice` primitives and then running a setuid-root helper whose page cache was
targeted.

### Possible investigation steps

- Review the grouped `host.name`, `user.name`, and `process.name` values in the alert, then inspect the original audit events for `process.executable`, `process.command_line`, `process.pid`, parent process details, working directory, and session or login context.
- Determine whether the process is an interpreter or ad-hoc binary. Public proof-of-concept behavior may appear as a short Python script using standard library modules and calls such as `socket.socket(38, 5, 0)`, `authencesn`, `os.splice`, or `MSG_MORE`.
- Pivot on the same host, user, process name, and nearby timestamps for additional syscall activity from the same process tree, especially `splice`, `sendmsg`, `recvmsg`, or repeated `socket` activity.
- Look for execution of setuid-root binaries shortly after the AF_ALG socket creation, including `/usr/bin/su`, `/usr/bin/sudo`, `/usr/bin/passwd`, `/usr/bin/mount`, `/usr/bin/newgrp`, `/usr/bin/gpasswd`, or `/usr/bin/chfn`.
- Check for evidence of a UID transition to root from the same process tree, followed by root shell activity, persistence creation, credential access, or security control tampering.
- Check container fields such as `container.id` and `container.image.name`. Because this primitive abuses the shared host page cache, container-originated activity should be treated as a possible node-compromise attempt.
- Confirm the host kernel version and distribution advisory status. Prioritize hosts running vulnerable kernels or untrusted container workloads.

### False positive analysis

- Legitimate unprivileged AF_ALG consumers are rare, but some environments may use kernel crypto testing, disk encryption tooling, IPsec helpers, HSM integration software, or approved research systems.
- Verify whether the process name and executable path are expected on the host. Confirm that the user identity, host role, and execution time align with documented administrative or testing activity.
- If the activity is expected, add a narrow exception using stable values such as `process.executable`, `user.id`, and `host.id` rather than broad process-name-only exclusions.
- Treat interpreter-driven AF_ALG use, activity from temporary directories, or AF_ALG use inside containers as suspicious unless there is a documented reason.

### Response and remediation

- Isolate the affected Linux host if unauthorized AF_ALG activity cannot be quickly ruled out. Treat confirmed exploitation as root compromise.
- Terminate the alerting process and any suspicious child processes. Preserve memory, exploit scripts, shell history, temporary files, and relevant audit logs for forensic review.
- Inspect setuid-root binaries that may have been targeted. Remember that the vulnerable write affects the page cache, not the on-disk file; normal file-integrity checks may not show the corrupted in-memory state.
- Rebuild or reimage the host if successful privilege escalation cannot be ruled out. Rotate credentials, SSH keys, tokens, and secrets that were accessible to the affected user or any root shell spawned afterward.
- Patch the kernel with the vendor fix for CVE-2026-31431. Until patched, consider blocking `algif_aead` module loading or restricting AF_ALG socket creation via seccomp for untrusted workloads.
- For containerized environments, patch the underlying node kernel. Rebuilding container images does not remediate the host kernel vulnerability.
"""
references = [
    "https://xint.io/blog/copy-fail-linux-distributions",
    "https://nvd.nist.gov/vuln/detail/CVE-2026-31431",
    "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a664bf3d603d",
    "https://www.kernel.org/doc/html/latest/crypto/userspace-if.html",
]
risk_score = 73
rule_id = "1c28becc-ec0b-4e6d-81a5-899d00348089"
setup = """## Setup

This rule requires data coming in from one of the following integrations:
- Auditbeat
- Auditd Manager

### Auditbeat Setup
Auditbeat is a lightweight shipper that you can install on your servers to audit user and process activity. It can collect and centralize events from the Linux Audit Framework.

#### The following steps should be executed in order to add Auditbeat on a Linux system:
- Elastic provides repositories available for APT and YUM-based distributions. To install the repositories, follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html).
- For complete "Setup and Run Auditbeat" instructions, refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).
- To run Auditbeat on Docker or Kubernetes, follow the relevant deployment guides in the Auditbeat documentation.

### Auditd Manager Integration Setup
The Auditd Manager integration receives audit events from the Linux Audit Framework, which is part of the Linux kernel. Auditd Manager provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon.

#### The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" on a Linux system:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Auditd Manager" and select the integration to see more details.
- Click "Add Auditd Manager".
- Configure the integration name and optionally add a description.
- Review optional and advanced settings as needed.
- Add the newly installed "auditd manager" integration to an existing or new agent policy, and deploy the agent on Linux systems where detection is desired.
- Click "Save and Continue".
- For more details on the integration, refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).

#### Rule Specific Setup Note
This detection relies on auditing one of the 3 event types `socket` or `splice` or `bound-socket` event. If your environment uses a minimal audit ruleset, add rules similar to the following
in the integration's "audit rules" configuration:

```
-a always,exit -F arch=b64 -S socket -k socket_syscall
-a always,exit -F arch=b32 -S socketcall -k socket_syscall
-a always,exit -F arch=b64 -S splice -k splice-syscall
-a always,exit -F arch=b32 -S splice -k splice-syscall
-a always,exit -F arch=b64 -S bind -k socket_bound
-a always,exit -F arch=b32 -S bind -k socket_bound
```
"""
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Use Case: Vulnerability",
    "Tactic: Privilege Escalation",
    "Data Source: Auditd Manager",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
sequence with maxspan=60s
  [any where host.os.type == "linux" and    
   (
    (event.category == "process" and auditd.data.syscall == "socket" and auditd.data.a0 == "26") or 
    (event.category == "process" and auditd.data.syscall == "splice") or 
    (event.category == "network" and event.action == "bound-socket" and data_stream.dataset == "auditd_manager.auditd" and ?auditd.data.socket.family == "38") 
    )  
   and user.id != "0"]  by process.pid, host.id, user.id with runs=10
  [process where host.os.type == "linux"  and event.action == "executed" and 
   (
     (user.effective.id == "0" and user.id != "0") or 
     (process.name in ("bash", "sh", "zsh", "dash", "fish", "ksh", "busybox") and 
      process.args in ("-c", "--command", "-ic", "-ci", "-cl", "-lc", "-bash", "-sh", "-zsh", "-dash", "-fish", "-ksh"))
    )] by process.parent.pid, host.id, user.id
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1068"
name = "Exploitation for Privilege Escalation"
reference = "https://attack.mitre.org/techniques/T1068/"

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



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

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

[rule]
author = ["Elastic"]
description = """
This rule detects the use of SSH options that may indicate tunneling or port forwarding on Linux systems. This behavior
is commonly associated with malicious activity, such as establishing a port forward, proxy or an encrypted tunnel to
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 Linux Tunneling and/or Port Forwarding via SSH Option"
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 Linux Tunneling and/or Port Forwarding via SSH Option

SSH is a secure protocol used for encrypted communication over networks, often employed for remote administration. Adversaries exploit SSH options like port forwarding to create tunnels, facilitating covert data exfiltration or unauthorized access. The detection rule identifies suspicious SSH commands indicative of tunneling by monitoring specific SSH options, helping to flag potential misuse for further investigation.

### Possible investigation steps

- Review the process command line details to identify the specific SSH options used, such as ProxyCommand, LocalForward, RemoteForward, DynamicForward, Tunnel, GatewayPorts, ExitOnForwardFailure, or ProxyJump, to understand the nature of the potential tunneling or port forwarding.
- Examine the user account associated with the SSH process to determine if the activity aligns with their typical behavior or if it appears suspicious.
- Check the source and destination IP addresses involved in the SSH connection to identify any unusual or unauthorized endpoints that may indicate malicious activity.
- Investigate the timing and frequency of the SSH connections to assess whether they coincide with known business operations or if they suggest unauthorized access patterns.
- Correlate the event with other security logs or alerts from the same host or network segment to identify any additional indicators of compromise or related suspicious activities.

### False positive analysis

- Legitimate administrative tasks using SSH options like ProxyCommand or LocalForward can trigger the rule. To manage this, create exceptions for known administrative scripts or users frequently using these options for valid purposes.
- Automated backup or synchronization processes that use SSH tunneling for secure data transfer may be flagged. Identify these processes and exclude them by specifying the associated process names or user accounts.
- Development or testing environments where developers use SSH tunneling for accessing remote services might cause alerts. Implement exceptions for specific IP addresses or user groups associated with these environments.
- Monitoring or logging tools that utilize SSH for secure data collection can be mistaken for malicious activity. Whitelist these tools by their process names or command-line patterns to prevent false positives.
- Internal network services that rely on SSH port forwarding for legitimate communication should be reviewed and excluded based on their known behavior and usage patterns.

### Response and remediation

- Immediately isolate the affected Linux system from the network to prevent further unauthorized access or data exfiltration.
- Terminate any suspicious SSH sessions identified by the detection rule to halt potential tunneling or port forwarding activities.
- Conduct a thorough review of SSH configuration files and logs on the affected system to identify unauthorized changes or access patterns.
- Reset credentials for any accounts that were used in the suspicious SSH activity to prevent further unauthorized access.
- Implement network segmentation to limit SSH access to only necessary systems and services, reducing the risk of lateral movement.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised.
- Enhance monitoring and logging of SSH activities across the network to detect similar threats in the future, ensuring alerts are promptly reviewed and acted upon.
"""
references = [
    "https://blog.bitsadmin.com/living-off-the-foreign-land-windows-as-offensive-platform",
    "https://book.hacktricks.xyz/generic-methodologies-and-resources/tunneling-and-port-forwarding",
]
risk_score = 21
rule_id = "ef395dff-be12-4a6e-8919-d87d627c2174"
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: Command and Control",
    "Data Source: Elastic Defend",
    "Data Source: Elastic Endgame",
    "Data Source: Crowdstrike",
    "Data Source: SentinelOne",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
process.name in ("ssh", "sshd") and process.args like "-o*" and
process.command_line like~ (
  "*ProxyCommand*", "*LocalForward*", "*RemoteForward*", "*DynamicForward*", "*Tunnel*", "*GatewayPorts*",
  "*ExitOnForwardFailure*", "*ProxyCommand*", "*ProxyJump*"
) and 
not (
  ?process.parent.args == "/usr/bin/pvedaemon" or
  ?process.parent.command_line in ("pvedaemon", "pve-ha-lrm") or
  ?process.working_directory like "*ansible*" or
  process.command_line like "*ansible*"
)
'''
[[rule.threat]]
framework = "MITRE ATT&CK"

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

[[rule.threat.technique]]
id = "T1572"
name = "Protocol Tunneling"
reference = "https://attack.mitre.org/techniques/T1572/"

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

[rule]
description = """
Identifies Snipping Tool started with an ms-screensketch deep link whose filePath parameter points at a remote resource
(URL-encoded UNC, literal UNC, or http-based value), consistent with public research on CVE-2026-33829. Affected builds
can coerce an authenticated SMB connection and leak Net-NTLM responses for the current user when the handler processes
an attacker-controlled filePath. Apply the vendor security update from the April 14, 2026 release train when available.
"""
id = "b2c4d6e8-0a1f-4b3c-8d9e-1f2a3b4c5d6e"
license = "Elastic License v2"
name = "Potential Net-NTLM Coercion via Snipping Tool ms-screensketch URI (CVE-2026-33829)"
os_list = ["windows"]
reference = [
    "https://github.com/blackarrowsec/redteam-research/tree/master/CVE-2026-33829",
    "https://www.cve.org/CVERecord?id=CVE-2026-33829",
]
version = "1.0.1"

query = '''
process where event.action == "start" and
  process.name : "SnippingTool.exe" and
  (
    process.args : (
      "ms-screensketch:edit?&filePath=%5C%5C*",
      "ms-screensketch:edit?&filePath=http*",
      "ms-screensketch:edit?&filePath=\\\\*"
    ) or
    process.command_line : (
      "*ms-screensketch*edit*&filePath=%5C%5C*",
      "*ms-screensketch*edit*&filePath=http*",
      "*ms-screensketch*edit*&filePath=*\\\\*"
    )
  ) and 
  process.parent.executable != null and not process.parent.executable : ("?:\\Windows\\System32\\svchost.exe", "?:\\Program Files\\WindowsApps\\Microsoft.ScreenSketch_*\\SnippingTool\\SnippingTool.exe")
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1187"
name = "Forced Authentication"
reference = "https://attack.mitre.org/techniques/T1187/"


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

[internal]
min_endpoint_version = "7.15.0"

[rule]
description = """
Detects abuse of the Windows finger.exe LOLBin to download and execute remote payloads, a technique observed in ClickFix
campaigns. Adversaries copy finger.exe from System32 to a user Temp directory under a benign-looking name such as
ct.exe, then invoke it with a confirm@ remote host argument and pipe the response into cmd for execution.
"""
id = "3260bb0d-7b35-4c7a-b59a-35ca8dbd3856"
license = "Elastic License v2"
name = "Potential Payload Download via Finger LOLBin"
os_list = ["windows"]
reference = [
    "https://lolbas-project.github.io/lolbas/Binaries/Finger/",
    "https://www.microsoft.com/en-us/security/blog/2025/08/21/think-before-you-clickfix-analyzing-the-clickfix-social-engineering-technique/",
    "https://mrd0x.com/filefix-clickfix-alternative/",
]
version = "1.0.1"

query = '''
process where event.action == "start" and
     (process.pe.original_file_name == "finger.exe" or process.name : "finger.exe") and
      process.command_line like "*@*" and not process.command_line like "*@localhost*" and 
      process.parent.name : ("cmd.exe", "powershell.exe", "WindowsTerminal.exe", "wt.exe", "explorer.exe")
'''

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

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

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



[threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[threat.technique.subtechnique]]
id = "T1059.003"
name = "Windows Command Shell"
reference = "https://attack.mitre.org/techniques/T1059/003/"


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



[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1218"
name = "System Binary Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1218/"


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


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

[internal]
min_endpoint_version = "8.10.0"

[metadata]
creation_date = "2024/03/27"
integration = ["windows"]
maturity = "production"
updated_date = "2026/04/27"

[rule]
author = ["Elastic"]
description = """
Detects PowerShell scripts associated with NTLM relay or pass-the-hash tooling and SMB/NTLM negotiation
artifacts. Attackers use relay and PtH techniques to authenticate without passwords and pivot to other systems.
"""
from = "now-9m"
index = ["logs-windows.powershell*", "winlogbeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "Potential PowerShell Pass-the-Hash/Relay Script"
references = [
    "https://github.com/Kevin-Robertson/Invoke-TheHash/blob/master/Invoke-WMIExec.ps1",
    "https://github.com/Kevin-Robertson/Invoke-TheHash/blob/master/Invoke-SMBExec.ps1",
    "https://github.com/dafthack/Check-LocalAdminHash/blob/master/Check-LocalAdminHash.ps1",
    "https://github.com/nettitude/PoshC2/blob/master/resources/modules/Invoke-Tater.ps1",
    "https://github.com/Kevin-Robertson/Inveigh/blob/master/Inveigh.ps1",
]
risk_score = 73
rule_id = "951779c2-82ad-4a6c-82b8-296c1f691449"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
    "Data Source: PowerShell Logs",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.category:process and host.os.type:windows and
  powershell.file.script_block_text : (
    ("NTLMSSPNegotiate" and ("NegotiateSMB" or "NegotiateSMB2")) or
    "4E544C4D53535000" or
    "0x4e,0x54,0x4c,0x4d,0x53,0x53,0x50" or
    "0x4e,0x54,0x20,0x4c,0x4d" or
    "0x53,0x4d,0x42,0x20,0x32" or
    "0x81,0xbb,0x7a,0x36,0x44,0x98,0xf1,0x35,0xad,0x32,0x98,0xf0,0x38"
  ) and
  not file.directory : "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Downloads"
'''

note = """## Triage and analysis

### Investigating Potential PowerShell Pass-the-Hash/Relay Script

#### Possible investigation steps

- Does the visible script content implement relay-listener behavior, pass-the-hash execution, target validation, or more than one?
  - Focus: `powershell.file.script_block_text` and any file-backed `file.path`.
  - Implication: escalate when the fragment builds NTLMSSP/SMB messages, starts HTTP/SMB/proxy listeners, forwards authentication, references WMI/SMB/WinRM helpers, or pairs byte arrays with target selection; lower suspicion only for parser or lab text with no targeting, listener, credential, or execution logic.

- Does full script reconstruction reveal target lists, credential material, service names, or listener settings the matching fragment did not show?
  - Why: script block logging often splits relay mode, target configuration, and execution helpers into separate fragments.
  - Focus: `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, and reconstructed `powershell.file.script_block_text` on `host.id`; reassemble by `powershell.sequence` and treat missing fragments as unresolved. $investigate_0
  - Implication: escalate on remote targets, password hashes, "TargetList", "SMBRelayTarget", "wpad.dat", "WPAD", listener ports, service names, execution helpers, or fan-out logic; lower suspicion only for research or validation code with no credential material, targets, listener, or execution path.

- Which recovered PowerShell process explains launch context and downstream pivots?
  - Focus: If endpoint process telemetry exists, recover the matching process via `host.id + process.pid` before interpreting `process.*` or `process.parent.*`; if absent, keep launch context unresolved. Record `process.command_line`, `process.parent.executable`, `process.Ext.session_info.logon_type`, `process.Ext.authentication_id`, and `process.entity_id`. $investigate_1
  - Implication: escalate when the recovered launch shows encoded commands, remote-administration launchers, Office or browser parents, elevated context, or service/network logon sessions that do not fit the user; do not infer legitimacy from `process.pid` alone.

- Do authentication events show local operator context or relay/PtH follow-on?
  - Focus: same-`host.id`/`user.id` Windows Security events for `event.code` 4624, 4625, or 4648; review `source.ip`, `winlog.event_data.AuthenticationPackageName`, and `winlog.logon.type`. $investigate_2
  - Hint: bridge recovered `process.Ext.authentication_id` to `winlog.event_data.TargetLogonId` only for the local session; prove relay/PtH with same-host inbound NTLM without `user.id`, target-host 4624/4625, or DC-side 4776 for reconstructed targets or sources.
  - Implication: escalate when local, target-host, or DC authentication shows unexpected type 3 NTLM, repeated failures, privileged sessions, or explicit-credential use tied to reconstructed targets; missing authentication telemetry is unresolved, not benign.

- Do network events show outbound relay or hash-validation activity to targets named in the script?
  - Why: relay code often resolves targets, then reaches SMB, RPC, WinRM, or HTTP destinations; listener-only capture may not.
  - Focus: If endpoint network telemetry exists, scope same-host events to `host.id`, `process.pid`, and the alert window, or use reconstructed targets when process identity is unavailable; separate DNS (`dns.question.name`, `dns.resolved_ip`) from connections (`destination.ip`, `destination.port`). $investigate_3
  - Implication: escalate when the host fans out to named targets or reaches SMB, RPC, WinRM, or relay ports (80, 443, 445) outside the declared test scope; listener scripts stay suspicious with little outbound traffic when reconstruction shows "SMBRelayTarget", "wpad.dat", or similar relay-ready settings. Missing network telemetry is unresolved, not benign.

- If local evidence remains suspicious or incomplete, do related alerts widen the user or host scope?
  - Focus: related alerts for `user.id`; if quiet, compare `host.id` for adjacent relay, pass-the-hash, remote-service, persistence, or post-compromise alerts.
    - $investigate_4
    - $investigate_5
  - Implication: broaden when local evidence stays suspicious or unresolved and related alerts show connected relay, listener-only capture, hash-validation fan-out, or lateral-movement behavior; keep local when surrounding alerts are absent or confined to the same declared test scope.

- Weigh script intent, reconstruction, launch context, authentication follow-on, network contact, and related-alert scope: escalate when they align on unauthorized relay or pass-the-hash activity; close only when reconstructed content, launch, source, and available auth or network evidence support one controlled workflow with no contradictions; preserve and escalate if evidence is mixed or incomplete.

### False positive analysis

- Controlled testing, incident-response, or protocol-research workflows can trigger this rule when reconstructed `powershell.file.script_block_text` names only recognized targets or stays limited to parser/validation routines, recovered launch context matches the operator workflow, and authentication or network telemetry shows no live relay, listener, or execution outside scope. If engagement or change records exist, require alignment; otherwise, confirm recurring `user.id`, `host.id`, source pattern, recovered launch pattern, and target or port pattern across prior alerts from this rule. Do not close if hashes, listener ports, or follow-on authentication diverge.
- Before creating an exception, validate recurring `user.id`, `host.id`, recovered launch pattern, source pattern, and target set across prior alerts. Build the exception from that minimum workflow. Avoid exceptions on byte sequences alone, `user.name` alone, or host alone.

### Response and remediation

- If confirmed benign, reverse any temporary containment and document the script content, recovered launch chain, source path pattern, target set, and session origin or logon-type pattern that proved the lab, response, or troubleshooting workflow. Create an exception only if the same workflow recurs across prior alerts from this rule.
- If suspicious but unconfirmed, preserve the reconstructed `powershell.file.script_block_text`, `powershell.file.script_block_id`, fragment ordering metadata, recovered process and parent details, named targets, listener ports, service names, UNC paths, and related authentication or network evidence before destructive actions.
- Apply reversible containment first, such as host isolation if tolerable or temporary controls on exposed accounts and named targets. Avoid terminating processes or deleting artifacts until possible credential misuse and lateral movement scope is clearer.
- If confirmed malicious, isolate the endpoint when possible; otherwise escalate with the recorded `host.id`, recovered process identifiers, source IP values, named targets, and authentication evidence. Rotate or invalidate impacted credentials, review named systems for successful SMB/WMI/WinRM/service activity, restrict exposed NTLM pathways where supported, then remove only the scripts, services, scheduled tasks, persistence, or staging artifacts found during the investigation.
- Retain PowerShell Script Block Logging plus supporting endpoint, authentication, and network telemetry. Document adjacent variants such as listener-only capture, hash-validation fan-out, or non-PowerShell relay/pass-the-hash alerts for detection follow-up.
"""

setup = """## Setup

PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).
Setup instructions: https://ela.st/powershell-logging-setup
"""

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user.id",
    "user.domain",
    "powershell.file.script_block_text",
    "powershell.file.script_block_id",
    "powershell.sequence",
    "powershell.total",
    "file.path",
    "file.directory",
    "file.name",
    "process.pid",
    "host.name",
    "host.id",
    "powershell.file.script_block_length"
]

[transform]

[[transform.investigate]]
label = "All PowerShell 4104 fragments for this script on this host"
description = ""
providers = [
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "powershell.file.script_block_id", queryType = "phrase", value = "{{powershell.file.script_block_id}}", valueType = "string" },
    { excluded = false, field = "event.code", queryType = "phrase", value = "4104", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "Process events for the PowerShell instance"
description = ""
providers = [
  [
    { excluded = false, field = "process.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "Windows Security authentication events for the user"
description = ""
providers = [
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" },
    { excluded = false, field = "event.code", queryType = "phrase", value = "4624", valueType = "string" }
  ],
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" },
    { excluded = false, field = "event.code", queryType = "phrase", value = "4625", valueType = "string" }
  ],
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" },
    { excluded = false, field = "event.code", queryType = "phrase", value = "4648", valueType = "string" }
  ]
]
relativeFrom = "now-24h"
relativeTo = "now"

[[transform.investigate]]
label = "Network events for the PowerShell process"
description = ""
providers = [
  [
    { excluded = false, field = "process.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "Alerts associated with the user"
description = ""
providers = [
  [
    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
    { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

[[transform.investigate]]
label = "Alerts associated with the host"
description = ""
providers = [
  [
    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

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

[[rule.threat.technique]]
id = "T1557"
name = "Adversary-in-the-Middle"
reference = "https://attack.mitre.org/techniques/T1557/"

[[rule.threat.technique.subtechnique]]
id = "T1557.001"
name = "LLMNR/NBT-NS Poisoning and SMB Relay"
reference = "https://attack.mitre.org/techniques/T1557/001/"

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

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

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

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

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

[[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.002"
name = "Pass the Hash"
reference = "https://attack.mitre.org/techniques/T1550/002/"

[rule.threat.tactic]
id = "TA0008"
name = "Lateral Movement"
reference = "https://attack.mitre.org/tactics/TA0008/"