Elastic rules: 2z

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

[rule]
author = ["Elastic"]
description = """
Detects the deletion of an Amazon GuardDuty detector. GuardDuty provides continuous monitoring for malicious or
unauthorized activity across AWS accounts. Deleting the detector disables this visibility, stopping all threat detection
and removing existing findings. Adversaries may delete GuardDuty detectors to impair security monitoring and evade
detection during or after an intrusion. This rule identifies successful "DeleteDetector" API calls and can indicate a
deliberate defense evasion attempt.
"""
false_positives = [
    """
    The GuardDuty detector may be deleted by a system or network administrator. Verify whether the user identity, user
    agent, and/or hostname should be making changes in your environment. Detector deletions by unfamiliar users or hosts
    should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS GuardDuty Detector Deletion"
note = """## Triage and analysis

### Investigating AWS GuardDuty Detector Deletion

Amazon GuardDuty is a continuous threat detection service that analyzes CloudTrail, DNS, and VPC Flow Logs to identify malicious activity and compromised resources. Deleting a GuardDuty detector stops this monitoring entirely and permanently removes all historical findings for the affected AWS account. This rule detects successful `DeleteDetector` API calls, which may represent an attacker attempting to impair defenses and evade detection. Such actions should be rare and always performed under controlled administrative change processes.

#### Possible investigation steps

- **Identify the actor**
  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to determine who initiated the deletion.
  - Verify whether this principal normally performs GuardDuty configuration or administrative tasks.

- **Review request context**
  - Check `aws.cloudtrail.request_parameters` and `cloud.region` to confirm the targeted GuardDuty detector and scope of impact.
  - Determine whether multiple detectors or member accounts were affected (especially in delegated admin organizations).

- **Analyze source and access patterns**
  - Review `source.ip`, `user_agent.original` and `source.geo` fields for anomalous or previously unseen access locations or automation clients.
  - Check whether the deletion occurred outside standard maintenance windows or during a concurrent suspicious activity window.

- **Correlate with preceding or related activity**
  - Search for earlier GuardDuty configuration changes:
    - `StopMonitoringMembers`, `DisassociateMembers`, or `DeleteMembers`
    - IAM role or policy modifications reducing GuardDuty privileges
  - Look for other defense evasion indicators such as CloudTrail suspension, Security Hub configuration changes, or disabling of AWS Config rules.

- **Review historical GuardDuty findings**
  - Examine prior GuardDuty alerts and findings (if still retrievable) to determine whether the deletion followed significant detection activity.
  - Use centralized logs or security data lakes to recover findings removed from the console.

### False positive analysis

- **Authorized administrative actions**
  - Verify whether the deletion corresponds to legitimate account decommissioning, region cleanup, or migration activity.
- **Automation or IaC**
  - GuardDuty may be disabled temporarily during infrastructure provisioning or teardown in automated environments. 
    Confirm via CI/CD logs or Infrastructure-as-Code templates.
- **Organizational configuration changes**
  - Large organizations might consolidate GuardDuty under a delegated administrator account, causing detectors to be deleted in member accounts. 
    Validate these actions against security architecture changes.

### Response and remediation

- **Containment and restoration**
  - If unauthorized, immediately re-enable GuardDuty in the affected account and region using the `CreateDetector` API or AWS console.
  - Verify that findings aggregation and member account associations are restored to expected configurations.

- **Investigation**
  - Review CloudTrail for related privilege escalation or resource tampering events around the deletion time.
  - Assess whether any attacker activity occurred during the monitoring gap between deletion and restoration.

- **Recovery and hardening**
  - Restrict `guardduty:DeleteDetector` permissions to a limited administrative role.
  - Implement AWS Config rules or Security Hub controls to alert on changes to GuardDuty detectors or configuration states.
  - Enforce least privilege IAM policies, ensuring operational automation cannot disable GuardDuty outside maintenance workflows.
  - Document approved GuardDuty maintenance activities and correlate them with change tickets for traceability.

### Additional information
- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
"""
references = [
    "https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteDetector.html",
]
risk_score = 73
rule_id = "523116c0-d89d-4d7c-82c2-39e6845a78ef"
severity = "high"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS GuardDuty",
    "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: guardduty.amazonaws.com 
  and event.action: DeleteDetector 
  and event.outcome: success
  and not user_agent.original: (*Terraform* or *Pulumi*)
'''


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



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

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

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

[rule]
author = ["Elastic"]
description = """
Identifies creation or modification of a console login profile for an AWS IAM user via CreateLoginProfile or
UpdateLoginProfile. A login profile enables password-based console sign-in for an IAM user. Adversaries who obtain
programmatic credentials may create a login profile to add persistent interactive console access, or update an existing
profile to reset another user's password and take over the account, even after the original access keys are rotated.
Because console access for IAM users is increasingly provisioned through federation or IAM Identity Center, direct use
of these APIs by an unexpected principal warrants review. This rule targets IAM users (the userName parameter is
present); creation of a login profile for the account root user is covered by a separate rule.
"""
false_positives = [
    """
    Administrators and identity teams may legitimately create or reset console login profiles during user onboarding,
    password resets, or break-glass procedures. Verify the principal in "aws.cloudtrail.user_identity.arn", the target
    user in "aws.cloudtrail.request_parameters", and whether the change aligns with an approved request. Known
    administration roles and provisioning automation can be excluded after validation.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS IAM Login Profile Created or Modified for an IAM User"
note = """## Triage and analysis

### Investigating AWS IAM Login Profile Created or Modified for an IAM User

A login profile enables password-based AWS console access for an IAM user. "CreateLoginProfile" adds a console password to a user that did not have one, and "UpdateLoginProfile" changes the password of an existing profile. An adversary operating with stolen programmatic credentials can use "CreateLoginProfile" to establish persistent interactive access, or "UpdateLoginProfile" to reset a privileged user's password and hijack the account, retaining access even if the compromised access keys are later disabled.

Because IAM-user console access is commonly provisioned through federation or IAM Identity Center rather than these APIs directly, unexpected use is a meaningful signal. Note that a user changing their own password uses ChangePassword, not UpdateLoginProfile, so UpdateLoginProfile typically reflects an administrative (or adversarial) reset of another user.

### Possible investigation steps

- Identify the actor in "aws.cloudtrail.user_identity.arn", "aws.cloudtrail.user_identity.type", and "aws.cloudtrail.user_identity.session_context.session_issuer.arn", and review "source.ip", "source.as.organization.name", and "user_agent.original" to determine whether the action came from an expected network path or automation platform.
- Identify the target user in "aws.cloudtrail.request_parameters" and determine whether that user normally has console access and how privileged it is.
- Check "aws.cloudtrail.request_parameters" for "passwordResetRequired"; a value of false (or omitted) may indicate the actor set a password they intend to reuse.
- Correlate with surrounding activity by the same principal, such as CreateAccessKey, AttachUserPolicy, PutUserPolicy, virtual MFA registration, or a subsequent ConsoleLogin for the target user, which may indicate persistence or account takeover.

### False positive analysis

- Onboarding, password resets, and break-glass procedures legitimately use these APIs. Confirm the change is expected and exclude known administration roles or provisioning automation on "aws.cloudtrail.user_identity.arn" after validation.

### Response and remediation

- If the change is unauthorized, delete the login profile or reset the affected user's password, and revoke active console sessions for that user.
- Rotate or restrict credentials for the acting principal if compromise is suspected, and review any IAM permission changes or access keys created by the same session.
- Restrict "iam:CreateLoginProfile" and "iam:UpdateLoginProfile" to a small set of trusted administrators, and prefer federation or IAM Identity Center for console access.
"""
references = [
    "https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateLoginProfile.html",
    "https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateLoginProfile.html",
]
risk_score = 47
rule_id = "f4dc90eb-e77e-4f0e-b18b-eb50da9e827e"
setup = """This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details."""
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS IAM",
    "Use Case: Identity and Access Audit",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "iam.amazonaws.com"
    and event.action: ("CreateLoginProfile" or "UpdateLoginProfile")
    and event.outcome: "success"
    and not aws.cloudtrail.user_identity.type: "AWSService"
    and not user_agent.original: (*terraform* or *pulumi* or *ansible*)
    and not aws.cloudtrail.user_identity.arn: (*terraform* or *pulumi* or *ansible*)
    and not source.as.organization.name: (Amazon* or AMAZON* or Google*)
    and not source.address: ("cloudformation.amazonaws.com" or "servicecatalog.amazonaws.com")
'''


[[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 = [
    "@timestamp",
    "user.name",
    "user_agent.original",
    "source.ip",
    "source.as.number",
    "source.as.organization.name",
    "aws.cloudtrail.user_identity.arn",
    "aws.cloudtrail.user_identity.type",
    "aws.cloudtrail.user_identity.access_key_id",
    "aws.cloudtrail.user_identity.session_context.session_issuer.arn",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
    "aws.cloudtrail.response_elements",
]

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

[rule]
author = ["Elastic"]
description = """
Identifies an Event Hub deletion in Azure. An Event Hub is an event processing service that ingests and processes large
volumes of events and data. An adversary may delete an Event Hub in an attempt to evade detection.
"""
false_positives = [
    """
    Event Hub deletions may be done by a system or network administrator. Verify whether the username, hostname, and/or
    resource name should be making changes in your environment. Event Hub deletions by unfamiliar users or hosts should
    be investigated. If known behavior is causing false positives, it can be exempted from the rule.
    """,
]
from = "now-9m"
index = ["logs-azure.activitylogs-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure Event Hub Deleted"
note = """## Triage and analysis

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

### Investigating Azure Event Hub Deleted

Azure Event Hub is a scalable data streaming platform and event ingestion service, crucial for processing large volumes of data in real-time. Adversaries may target Event Hubs to delete them, aiming to disrupt data flow and evade detection by erasing evidence of their activities. The detection rule monitors Azure activity logs for successful deletion operations, flagging potential defense evasion attempts by identifying unauthorized or suspicious deletions.

### Possible investigation steps

- Review the Azure activity logs to confirm the deletion event by checking the operation name "MICROSOFT.EVENTHUB/NAMESPACES/EVENTHUBS/DELETE" and ensure the event outcome is marked as Success.
- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs.
- Investigate the context of the deletion by reviewing recent activities performed by the identified user or service principal to determine if there are any other suspicious actions.
- Check for any recent changes in permissions or roles assigned to the user or service principal to assess if the deletion was authorized or if there was a potential privilege escalation.
- Correlate the deletion event with other security alerts or incidents in the environment to identify if this action is part of a larger attack pattern or campaign.
- Communicate with relevant stakeholders or teams to verify if the deletion was part of a planned operation or maintenance activity.

### False positive analysis

- Routine maintenance or updates by authorized personnel can trigger deletion logs. Verify if the deletion aligns with scheduled maintenance activities and exclude these operations from alerts.
- Automated scripts or tools used for managing Azure resources might delete Event Hubs as part of their normal operation. Identify these scripts and whitelist their activity to prevent false positives.
- Test environments often involve frequent creation and deletion of resources, including Event Hubs. Exclude known test environments from monitoring to reduce noise.
- Changes in organizational policies or restructuring might lead to legitimate deletions. Ensure that such policy-driven deletions are documented and excluded from alerts.
- Misconfigured automation or deployment processes can inadvertently delete Event Hubs. Regularly review and update configurations to ensure they align with intended operations and exclude these from alerts if verified as non-threatening.

### Response and remediation

- Immediately isolate the affected Azure Event Hub namespace to prevent further unauthorized deletions or modifications. This can be done by restricting access through Azure Role-Based Access Control (RBAC) and network security groups.
- Review and revoke any suspicious or unauthorized access permissions associated with the deleted Event Hub. Ensure that only authorized personnel have the necessary permissions to manage Event Hubs.
- Restore the deleted Event Hub from backups if available, or reconfigure it to resume normal operations. Verify the integrity and completeness of the restored data.
- Conduct a thorough audit of recent Azure activity logs to identify any other unauthorized actions or anomalies that may indicate further compromise.
- Escalate the incident to the security operations team for a detailed investigation into the root cause and to assess the potential impact on other Azure resources.
- Implement additional monitoring and alerting for Azure Event Hub operations to detect and respond to similar unauthorized activities promptly.
- Review and update security policies and access controls for Azure resources to prevent recurrence, ensuring adherence to the principle of least privilege.

## Setup

The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-about",
    "https://azure.microsoft.com/en-in/services/event-hubs/",
    "https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-features",
]
risk_score = 47
rule_id = "e0f36de1-0342-453d-95a9-a068b257b053"
severity = "medium"
tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Log Auditing", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.EVENTHUB/NAMESPACES/EVENTHUBS/DELETE" and event.outcome:(Success or success)
'''


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

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

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

[rule]
description = """
Identifies attempts to install a new chromium browser native messaging application via registry change. Adversaries may
install a rogue browser native messaging host to maintain persistence.
"""
id = "f906c1f1-926e-4602-8287-1edc9667d2ad"
license = "Elastic License v2"
name = "Browser Native Messaging Registry Modification"
os_list = ["windows"]
reference = [
    "https://developer.chrome.com/docs/apps/nativeMessaging/",
    "https://www.trendmicro.com/en_us/research/23/b/earth-kitsune-delivers-new-whiskerspy-backdoor.html",
]
version = "1.0.21"

query = '''
registry where
  (process.code_signature.trusted == false or process.code_signature.exists == false) and
   not process.code_signature.status : ("errorExpired", "errorCode_endpoint*") and
   not user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-19") and
   not process.executable : ("?:\\Program Files\\*.exe", "?:\\Program Files (x86)\\*", 
                             "?:\\Users\\*\\AppData\\Local\\*\\Free Download Manager\\fdm.exe") and
   registry.path : "HK*\\Software\\*\\NativeMessagingHosts\\*" and registry.data.strings : "*.json*" and
   not registry.data.strings : ("*:\\Program Files\\*", "*:\\Program Files (x86)\\*") and 
   not process.name : "winmixClickOnceHelper*.exe"
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1176"
name = "Software Extensions"
reference = "https://attack.mitre.org/techniques/T1176/"
[[threat.technique.subtechnique]]
id = "T1176.001"
name = "Browser Extensions"
reference = "https://attack.mitre.org/techniques/T1176/001/"



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


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

[internal]
min_endpoint_version = "8.1.0"

[metadata]
creation_date = "2025/01/16"
integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2025/12/22"

[rule]
author = ["Elastic"]
description = """
This rule detects the extraction of an initramfs image using the "cpio" command on Linux systems. The "cpio" command is
used to create or extract cpio archives. Attackers may extract the initramfs image to modify the contents or add
malicious files, which can be leveraged to maintain persistence on the system.
"""
from = "now-9m"
index = [
    "logs-endpoint.events.process*",
    "endgame-*",
    "auditbeat-*",
    "logs-auditd_manager.auditd-*",
    "logs-crowdstrike.fdr*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Initramfs Extraction via CPIO"
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 Initramfs Extraction via CPIO

Initramfs is a temporary filesystem used during the Linux boot process, containing essential drivers and scripts. Attackers may exploit the `cpio` command to extract and modify initramfs, embedding malicious files to ensure persistence. The detection rule identifies suspicious `cpio` usage by monitoring process execution patterns, excluding legitimate parent processes, to flag potential threats.

### Possible investigation steps

- Review the process execution details to confirm the presence of the cpio command with arguments "-H" or "--format" and "newc" to ensure the alert is not a false positive.
- Investigate the parent process of the cpio command to determine if it is an unexpected or unauthorized process, as legitimate processes like mkinitramfs or dracut should be excluded.
- Check the execution path of the parent process to verify if it matches any known legitimate paths such as "/usr/share/initramfs-tools/*" or "/nix/store/*".
- Analyze the timeline of events around the cpio execution to identify any preceding or subsequent suspicious activities that might indicate a broader attack or persistence mechanism.
- Examine the system for any unauthorized modifications or additions to the initramfs image that could indicate tampering or the presence of malicious files.
- Correlate the alert with other security data sources like Elastic Endgame, Elastic Defend, or Crowdstrike to gather additional context and assess the scope of the potential threat.

### False positive analysis

- Legitimate system updates or maintenance activities may trigger the rule when tools like mkinitramfs or dracut are used. To handle this, ensure these processes are excluded by verifying that the parent process is mkinitramfs or dracut.
- Custom scripts or automation tools that manage initramfs might use cpio in a non-malicious context. Review these scripts and add their parent process names or paths to the exclusion list if they are verified as safe.
- Systems using non-standard initramfs management tools located in directories like /usr/share/initramfs-tools or /nix/store may cause false positives. Confirm these tools' legitimacy and update the exclusion paths accordingly.
- Development or testing environments where initramfs is frequently modified for legitimate reasons can generate alerts. Consider creating environment-specific exceptions to reduce noise while maintaining security in production systems.

### Response and remediation

- Isolate the affected system from the network to prevent further unauthorized access or spread of potential malware.
- Terminate any suspicious processes related to the `cpio` command that do not have legitimate parent processes, such as `mkinitramfs` or `dracut`.
- Conduct a thorough review of the extracted initramfs contents to identify and remove any unauthorized or malicious files.
- Restore the initramfs from a known good backup to ensure system integrity and remove any potential persistence mechanisms.
- Monitor the system for any further suspicious activity, particularly related to the `cpio` command, to ensure the threat has been fully mitigated.
- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.
- Update security policies and procedures to include specific checks for unauthorized `cpio` usage and enhance detection capabilities for similar threats."""
risk_score = 21
rule_id = "17b3fcd1-90fb-4f5d-858c-dc1d998fa368"
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: Persistence",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Auditd Manager",
    "Data Source: Crowdstrike",
    "Data Source: SentinelOne",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed") and
process.name == "cpio" and process.args in ("-H", "--format") and process.args == "newc" and
not (
  process.parent.name in ("mkinitramfs", "dracut") or
  ?process.parent.executable like~ ("/usr/share/initramfs-tools/*", "/nix/store/*") or
  ?process.parent.args in (
    "/bin/dracut", "/usr/share/initramfs-tools/hooks/amd64_microcode", "/usr/bin/dracut", "/usr/sbin/mkinitramfs",
    "/usr/sbin/dracut", "/usr/bin/update-microcode-initrd"
  ) or
  process.args like ("/var/tmp/mkinitramfs_*", "/tmp/tmp.*/mkinitramfs_*") or
  ?process.working_directory like (
    "/var/tmp/mkinitramfs-*", "/tmp/microcode-initrd_*", "/var/tmp/mkinitramfs-*", "/var/tmp/dracut.*",
    "/var/tmp/mkinitramfs_*", "/var/tmp/supermin*/init.d"
  )
)
'''

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

[[rule.threat.technique]]
id = "T1542"
name = "Pre-OS Boot"
reference = "https://attack.mitre.org/techniques/T1542/"

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

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

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

[metadata]
creation_date = "2022/07/05"
integration = ["kubernetes"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
This rules detects an attempt to create or modify a pod attached to the host network. HostNetwork allows a pod to use
the node network namespace. Doing so gives the pod access to any service running on localhost of the host. An attacker
could use this access to snoop on network activity of other pods on the same node or bypass restrictive network policies
applied to its given namespace.
"""
false_positives = [
    """
    An administrator or developer may want to use a pod that runs as root and shares the hosts IPC, Network, and PID
    namespaces for debugging purposes. If something is going wrong in the cluster and there is no easy way to SSH onto
    the host nodes directly, a privileged pod of this nature can be useful for viewing things like iptable rules and
    network namespaces from the host's perspective. Add exceptions for trusted container images using the query field
    "kubernetes.audit.requestObject.spec.container.image"
    """,
]
index = ["logs-kubernetes.audit_logs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Kubernetes Pod Created With HostNetwork"
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 Kubernetes Pod Created With HostNetwork

Kubernetes allows pods to connect to the host's network namespace using HostNetwork, granting them direct access to the node's network interfaces. This capability can be exploited by attackers to monitor or intercept network traffic, potentially bypassing network policies. The detection rule identifies suspicious pod creation or modification events with HostNetwork enabled, excluding known benign images, to flag potential privilege escalation attempts.

### Possible investigation steps

- Review the Kubernetes audit logs to identify the source of the pod creation or modification event, focusing on the user or service account associated with the action.
- Examine the pod's configuration details, especially the containers' images, to determine if any unauthorized or suspicious images are being used, excluding known benign images like "docker.elastic.co/beats/elastic-agent:8.4.0".
- Investigate the network activity of the node where the pod is running to identify any unusual traffic patterns or potential data exfiltration attempts.
- Check the Kubernetes RBAC (Role-Based Access Control) settings to ensure that the user or service account has appropriate permissions and is not overly privileged.
- Assess the necessity of using HostNetwork for the pod in question and determine if it can be reconfigured to operate without this setting to reduce potential security risks.

### False positive analysis

- Pods used for monitoring or logging may require HostNetwork access to gather network data across nodes. Users can exclude these by adding their specific container images to the exception list in the detection rule.
- Certain system-level services or infrastructure components might need HostNetwork for legitimate reasons, such as network plugins or ingress controllers. Identify these services and update the rule to exclude their specific images or namespaces.
- Development or testing environments might frequently create pods with HostNetwork for debugging purposes. Consider creating a separate rule or environment-specific exceptions to avoid alert fatigue in these scenarios.
- Pods that are part of a known and trusted deployment process, which require HostNetwork for valid operational reasons, should be documented and excluded from the rule to prevent unnecessary alerts.

### Response and remediation

- Immediately isolate the affected pod by cordoning the node to prevent new pods from being scheduled and draining existing pods to other nodes, except the suspicious one.
- Terminate the suspicious pod to stop any potential malicious activity and prevent further network access.
- Review and revoke any unnecessary permissions or roles associated with the service account used by the pod to limit privilege escalation opportunities.
- Conduct a thorough audit of network policies to ensure they are correctly configured to prevent unauthorized access to the host network.
- Escalate the incident to the security operations team for further investigation and to determine if any data was accessed or exfiltrated.
- Implement additional monitoring and alerting for any future pod creations with HostNetwork enabled to quickly detect similar threats.
- Review and update Kubernetes RBAC policies to enforce the principle of least privilege, ensuring only trusted entities can create pods with HostNetwork enabled.

## Setup

The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
references = [
    "https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections",
    "https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces",
    "https://bishopfox.com/blog/kubernetes-pod-privilege-escalation",
]
risk_score = 47
rule_id = "12cbf709-69e8-4055-94f9-24314385c27e"
severity = "medium"
tags = [
    "Data Source: Kubernetes",
    "Domain: Kubernetes",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
data_stream.dataset:kubernetes.audit_logs and kubernetes.audit.annotations.authorization_k8s_io/decision:allow and
kubernetes.audit.objectRef.resource:pods and kubernetes.audit.verb:(create or patch or update) and
kubernetes.audit.requestObject.spec.hostNetwork:true and
not (
  kubernetes.audit.requestObject.spec.containers.image:(
    *eks/observability/aws-for-fluent-bit* or *eks/observability/cloudwatch-agent* or *elastic-agent* or *quay/tigera* or *tigera/operator* or
    docker.io/bitnami/node-exporter* or docker.io/rancher/mirrored-calico-operator* or quay.io/calico/node* or quay.io/cephcsi/cephcsi* or
    quay.io/frrouting/frr* or quay.io/metallb/speaker* or quay.io/prometheus/node-exporter* or rancher/system-agent* or
    registry.crowdstrike.com/falcon-sensor* or registry.k8s.io/sig-storage/csi-node-driver-registrar*
  ) or
  kubernetes.audit.objectRef.namespace:(
    calico or calico-system or cilium or elastic or ingress-nginx or kube-system or noname-security-posture or openebs or sysdig-agent
  )
)
'''

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

[[rule.threat.technique]]
id = "T1611"
name = "Escape to Host"
reference = "https://attack.mitre.org/techniques/T1611/"

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

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

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

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

[metadata]
creation_date = "2026/04/23"
integration = ["kubernetes"]
maturity = "production"
updated_date = "2026/08/18"

[rule]
author = ["Elastic"]
description = """
Flags exec into a pod when the URL-decoded command payload resembles reverse-shell or bind-shell
one-liners invocation patterns. Legitimate debug sessions sometimes use similar building blocks, but together 
these patterns align with post-exploitation interactive access and command-and-control.
"""
from = "now-6m"
interval = "5m"
language = "esql"
license = "Elastic License v2"
name = "Kubernetes Pod Exec Potential Reverse Shell"
note = """## Triage and analysis

### Investigating Kubernetes Pod Exec Potential Reverse Shell

The rule inspects Kubernetes audit exec requestURI values, URL-decodes them, parses the command query fragment, and 
matches high-signal shell and socket idioms often used to obtain a fallback shell from inside a container.

### Possible investigation steps

- Identify the actor (kubernetes.audit.user.username, groups, impersonation), source IP, and user agent
  (human kubectl vs automation).
- Resolve the target namespace, pod, and container from kubernetes.audit.objectRef.* and correlate with
  workload ownership and change tickets.
- Pull the raw and decoded URI from the alert document and replay the inferred command in a sandbox only if policy
  allows—otherwise rely on audit and platform logs.
- Hunt nearby events from the same identity: secret reads, pods/exec to other workloads, RoleBinding
  changes, or anonymous API use.

### False positive analysis

- Security training, CTF-style images, or vendor diagnostics may include bash redirection or /dev/tcp examples;
  baseline approved images and break-glass accounts.
- Some observability or mesh sidecars use socat or sockets in ways that could overlap; validate container image and
  command lineage.

### Response and remediation

- If malicious, terminate the exec session, isolate the workload or node, rotate credentials reachable from the
  pod, and revoke pods/exec for the abused principal unless strictly required.
"""
references = [
    "https://attack.mitre.org/techniques/T1609/",
    "https://attack.mitre.org/techniques/T1059/",
]
risk_score = 73
rule_id = "f1a2b3c4-d5e6-4789-a012-3456789abc01"
severity = "high"
tags = [
    "Data Source: Kubernetes",
    "Data Source: Kubernetes API Server Audit Logs",
    "Domain: Kubernetes",
    "Platform: Kubernetes",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Tactic: Command and Control",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"
query = '''
FROM logs-kubernetes.audit_logs-* metadata _id, _index, _version
| WHERE kubernetes.audit.objectRef.subresource == "exec"
  AND kubernetes.audit.requestURI LIKE "*command=*"
| EVAL Esql.decoded_uri = URL_DECODE(kubernetes.audit.requestURI)
| GROK Esql.decoded_uri "%{DATA}/exec\\?%{DATA:raw_commands}&(?:container|stdin|stdout|stderr)=%{GREEDYDATA}"
| EVAL command = REPLACE(raw_commands, "command=", "")
| EVAL command = REPLACE(command, "&", " ")
| EVAL Esql.executed_command = REPLACE(command, "\\+", " ")
| WHERE Esql.executed_command IS NOT NULL AND command RLIKE """.*(/dev/tcp/|/dev/udp/|zsh/net/tcp|zsh/net/udp|nc\s+-e|ncat\s+-e|netcat\s+-e|nc\s.*\s-c\s|mkfifo|socat\s.*exec|socat\s.*pty|bash\s+-i\s+>&|0>&1|>&\s*/dev/tcp|import\s+socket.*connect|import\s+pty.*spawn|socket\.socket.*connect|IO::Socket::INET|fsockopen|TCPSocket\.new|/inet/tcp/).*""" AND 
  // local service health check patterns
  NOT command RLIKE """.*/dev/tcp/(localhost|127\.0\.0\.1)/(8080|8443|9090|3000|5000|8888|80|443).*"""
| KEEP Esql.*, user.name, user_agent.original, event.*, source.ip, kubernetes.audit.*, _id, _version, _index, data_stream.namespace
'''

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

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Detects write operations performed by Kubernetes service accounts against RBAC resources (Roles,
ClusterRoles, RoleBindings, ClusterRoleBindings). Service accounts typically do not manage RBAC
directly; this activity may indicate token abuse, misconfigured permissions, or unauthorized
privilege escalation.
"""
index = ["logs-kubernetes.audit_logs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Kubernetes Service Account Modified RBAC Objects"
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 Kubernetes Service Account Modified RBAC Objects

This rule detects Kubernetes service accounts performing allowed write actions on RBAC resources such as Roles and RoleBindings, which is atypical because service accounts rarely administer permissions. It matters because stolen or over-privileged service account tokens can silently alter authorization to gain or retain elevated access across the cluster. An attacker commonly uses a compromised workload’s token to create or patch a binding that grants cluster-admin privileges to their service account for persistent control.

### Possible investigation steps

- Retrieve the full audit event and diff the before/after RBAC object to identify newly granted subjects, verbs, resources, and cluster-admin or wildcard permissions.
- Trace the acting service account to its owning workload (Deployment/Pod) and node, then review recent image changes, restarts, exec sessions, and container logs around the event time for compromise indicators.
- Determine whether the change is attributable to an expected controller or GitOps/CI automation by correlating with change tickets, pipeline runs, and repository commits for RBAC manifests.
- Validate whether the service account token may be abused by checking for unusual API access patterns, source IPs/user agents, and cross-namespace activity compared to its baseline behavior.
- Contain if suspicious by reverting the RBAC change, rotating the service account token (and any mounted secrets), and tightening the service account’s Role/ClusterRole to least privilege.

### False positive analysis

- A platform automation running in-cluster (e.g., a controller or CI job using a service account) legitimately applies RBAC manifests during routine deployment, upgrades, or namespace onboarding, resulting in create/patch/update of Roles or RoleBindings.
- A Kubernetes operator or housekeeping workflow running under a service account intentionally adjusts RBAC as part of maintenance (e.g., rotating access, reconciling drift, or cleaning up obsolete bindings) and triggers allowed delete or update actions on RBAC resources.

### Response and remediation

- Immediately remove or quarantine the offending service account by deleting its RoleBindings/ClusterRoleBindings and restarting or scaling down the owning workload to stop further RBAC writes.
- Revert the unauthorized RBAC object changes by restoring the last known-good Roles/Bindings from GitOps/manifests (or `kubectl rollout undo` where applicable) and verify no new subjects gained wildcard or cluster-admin-equivalent access.
- Rotate credentials by recreating the service account or triggering token re-issuance, deleting any mounted legacy token secrets, and redeploying workloads to ensure old tokens cannot be reused.
- Hunt and eradicate persistence by searching for additional recently modified RBAC objects and newly created service accounts in the same namespaces, then remove unauthorized accounts/bindings and scan the implicated container images for backdoors.
- Escalate to incident response and cluster administrators immediately if any change grants `cluster-admin`, introduces `*` verbs/resources, or binds a service account to privileged ClusterRoles across namespaces.
- Harden going forward by enforcing least-privilege RBAC, enabling admission controls to restrict RBAC modifications to approved identities/namespaces, and using short-lived projected service account tokens with workload identity constraints.
"""
references = [
    "https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control",
]
risk_score = 47
rule_id = "f2e21713-1eac-4908-a782-1b49c7e9d53b"
severity = "medium"
tags = [
    "Data Source: Kubernetes",
    "Domain: Kubernetes",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
data_stream.dataset:"kubernetes.audit_logs" and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and
kubernetes.audit.user.username:(
  system\:serviceaccount\:* and not (
    "system:serviceaccount:kube-system:clusterrole-aggregation-controller" or
    "system:serviceaccount:kube-system:generic-garbage-collector"
  )
) and
kubernetes.audit.objectRef.resource:("clusterrolebindings" or "clusterroles" or "rolebindings" or "roles") and
kubernetes.audit.verb:("create" or "delete" or "patch" or "update")
'''

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

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

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

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

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

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

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

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

[metadata]
creation_date = "2020/02/18"
maturity = "production"
promotion = true
updated_date = "2025/03/21"

[rule]
author = ["Elastic"]
description = """
Elastic Endgame detected Malware. Click the Elastic Endgame icon in the event.module column or the link in the
rule.reference column for additional information.
"""
from = "now-2m"
index = ["endgame-*"]
interval = "1m"
language = "kuery"
license = "Elastic License v2"
max_signals = 1000
name = "Malware - Detected - Elastic Endgame"
risk_score = 99
rule_id = "0a97b20f-4144-49ea-be32-b540ecc445de"
setup = """## Setup

### Additional notes

For information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).
"""
severity = "critical"
tags = ["Data Source: Elastic Endgame", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:file_classification_event or endgame.event_subtype_full:file_classification_event)
'''
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 Malware - Detected - Elastic Endgame

Elastic Endgame is a security solution that provides endpoint protection by monitoring and analyzing system activities to detect malicious behavior. Adversaries may exploit this technology by attempting to bypass its detection capabilities or by executing malware that mimics legitimate processes. The detection rule identifies suspicious file classification events, flagging potential malware activities with a high-risk score, thus enabling swift investigation and response.

### Possible investigation steps

- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column to gather more context about the detected malware.
- Examine the specific file classification event by checking the event.action or endgame.event_subtype_full fields to understand the nature of the suspicious file activity.
- Analyze the endpoint's recent activity logs to identify any unusual behavior or patterns that coincide with the time of the alert.
- Investigate the source and destination of the file involved in the alert to determine if it is part of a known legitimate process or if it has been flagged in previous incidents.
- Check for any additional alerts or related events from the same endpoint or user to assess if this is part of a broader attack or isolated incident.
- Consult threat intelligence sources to see if the file or behavior matches known malware signatures or tactics, techniques, and procedures (TTPs).

### False positive analysis

- Legitimate software updates or installations may trigger file classification events. Users can create exceptions for known update processes to prevent these from being flagged as malware.
- System maintenance tasks, such as disk cleanup or defragmentation, might mimic suspicious file activities. Exclude these routine tasks by identifying their specific processes and adding them to the exception list.
- Security tools or antivirus software performing scans can generate alerts. Identify these tools and configure the rule to ignore their activities to reduce false positives.
- Custom scripts or automation tools used within the organization may be misclassified. Review these scripts and whitelist them if they are verified as safe and necessary for business operations.
- Frequent alerts from specific directories known to store temporary or cache files can be excluded by specifying these directories in the rule settings.

### Response and remediation

- Isolate the affected endpoint immediately to prevent further spread of the detected malware across the network.
- Terminate any suspicious processes identified by Elastic Endgame that are associated with the file classification event.
- Quarantine the suspicious files flagged by the detection rule to prevent execution and further analysis.
- Conduct a thorough scan of the isolated endpoint using updated antivirus and anti-malware tools to identify and remove any additional threats.
- Restore the affected system from a known good backup if malware removal is not feasible or if system integrity is compromised.
- Review and update endpoint protection policies to ensure they are configured to detect similar threats in the future.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""

[rule]
description = """
Identifies attempts to modify the memory protection from read only to read and execute, malware may use this approach to
avoid leaving suspicious allocation properties.
"""
id = "647e485d-4850-43da-9407-7618c9b23843"
license = "Elastic License v2"
name = "Memory Protection from Read to Execute"
os_list = ["windows"]
reference = ["https://www.elastic.co/security-labs/doubling-down-etw-callstacks"]
version = "1.0.5"

query = '''
api where process.Ext.api.name == "VirtualProtect" and
  process.Ext.api.parameters.protection == "R-X" and process.Ext.api.parameters.protection_old == "R--" and
  process.thread.Ext.call_stack_final_user_module.protection_provenance != "Kernel" and
  process.Ext.api.metadata.target_address_name != "Unknown" and process.Ext.api.parameters.size != 64 and
  process.thread.Ext.call_stack_final_user_module.name != "Unknown" and
  process.thread.Ext.call_stack_summary != null and process.thread.Ext.call_stack_final_user_module.name != null and
  process.thread.Ext.call_stack_final_user_module.protection_provenance != "Unknown" and
  not (process.thread.Ext.call_stack_summary == "ntdll.dll|Unbacked" and process.thread.Ext.call_stack_final_user_module.name == "Unbacked") and 
  not (process.thread.Ext.call_stack_final_user_module.name == "Unbacked" and process.thread.Ext.call_stack_final_user_module.protection_provenance == "Unbacked") and 
  not (process.thread.Ext.call_stack_final_user_module.name == "Undetermined" and process.Ext.api.behaviors == "truncated_stack") and 
  not (process.Ext.api.parameters.size == 4096 and
       process.thread.Ext.call_stack_final_user_module.path like "c:\\windows\\winsxs\\temp\\pendingdeletes\\$$deleteme*") and
  not (process.thread.Ext.call_stack_final_user_module.path in ("c:\\program files\\bold\\agent\\bold.exe", "c:\\program files\\bold\\agent\\boldengine.exe") and user.id == "S-1-5-18") and 
  not process.thread.Ext.call_stack_final_user_module.path == "c:\\windows\\syswow64\\cyinjct.dll" and
  process.Ext.api.summary in ("VirtualProtect( cryptsp.dll, 0x108, R-X, R-- )", "VirtualProtect( crypt32.dll, 0x108, R-X, R-- )") and
  process.thread.Ext.call_stack_final_user_module.hash.sha256 in
                                        ("6722b52ed34bbf1c1cbb2215130b725b66fd9bb2abc7ac7b9281ba9643b17498",
                                         "87628b8c8fba57a55383999de84a4f1a4ae6e37d735bb785bc29abba4d9ba701",
                                         "be636d9eb262f8db59bf793c35ba0b7fe25091f5351ca25f9fe5a90493b151a1",
                                         "bb6c1bae7516b2d61e7cbf94c10ec9287fcaab34550dec268d99cd605c24f0d3",
                                         "edd811ce347d68ebde7565a618cf93494f8b57e94d875c1717046a55c6865e1c", 
                                         "2ab9a610db6fba4d41c6b9e971588fec0fbb47e19f1590bc04696cb2a80fc447", 
                                         "0db3072535e19bb206277c726497f0dae6066b620a39c4502d8c0060032feaa6", 
                                         "8d328590dc4cadfb45e04fc1476e0989e98fffd6b97dc47f91b6a105a53dd221", 
                                         "466970a44c0998f43b350d850615ec01bb9ad0ad1d0991883f69c31d61563f8c",
                                         "1e8b5406e30074784409cf2d8d65dca376d7c51cea2458a99a635b087a8f96a5") and
  not _arraysearch(process.thread.Ext.call_stack_final_user_module.code_signature, $entry, $entry.trusted == true) and
  not process.thread.Ext.call_stack_final_user_module.protection_provenance_path like
                                     ("c:\\program files (x86)\\common files\\microsoft shared\\office??\\mso*.dll",
                                      "c:\\windows\\assembly\\nativeimages*.ni.dll",
                                      "c:\\windows\\system32\\spool\\drivers\\x64\\3\\ricoh_drv\\*.dll") and
  not _arraysearch(process.thread.Ext.call_stack, $entry,
                   $entry.symbol_info like ("c:\\windows\\sys?????\\cyinjct.dll*", 
                                            "c:\\windows\\sys?????\\user32.dll!DispatchMessage*",
                                            "c:\\windows\\sys?????\\ntdll.dll!LdrResolveDelayLoadedAPI*",
                                            "c:\\windows\\sys?????\\ntdll.dll!LdrLoadDll*",
                                            "c:\\windows\\sys?????\\ntdll.dll!LdrShutdownThread*")) and
  not _arraysearch(process.thread.Ext.call_stack, $entry,
                   $entry.callsite_trailing_bytes == "85c00f85fc000000448b4df0488d45f04c8d45e84889442420488d55e04883c9ff41ffd685c00f85d8000000813e504500000f85cc0000008b462885c00f84c1")
'''

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

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


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

[internal]
min_endpoint_version = "8.14.2"

[metadata]
creation_date = "2021/01/19"
integration = ["endpoint", "windows", "m365_defender"]
maturity = "production"
updated_date = "2026/04/29"

[rule]
author = ["Elastic"]
description = """
Identifies attempts to modify the WDigest security provider in the registry to force the user's password to be stored in
clear text in memory. Windows 8.1+ and Server 2012 R2+ disable WDigest plaintext credential caching by default, but
setting UseLogonCredential to 1 re-enables it, causing LSASS to retain cleartext passwords for subsequent interactive
logons. Adversaries abuse this to prepare for credential dumping from LSASS memory.
"""
from = "now-9m"
index = [
    "winlogbeat-*",
    "logs-endpoint.events.registry-*",
    "logs-windows.sysmon_operational-*",
    "endgame-*",
    "logs-m365_defender.event-*",
]
language = "eql"
license = "Elastic License v2"
name = "Modification of WDigest Security Provider"
references = [
    "https://www.csoonline.com/article/567747/how-to-detect-and-halt-credential-theft-via-windows-wdigest.html",
    "https://www.praetorian.com/blog/mitigating-mimikatz-wdigest-cleartext-credential-theft?edition=2019",
    "https://frsecure.com/compromised-credentials-response-playbook/",
    "https://www.elastic.co/security-labs/detect-credential-access",
]
risk_score = 73
rule_id = "d703a5af-d5b0-43bd-8ddb-7a5d500b7da5"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: Microsoft Defender XDR",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
registry where host.os.type == "windows" and event.type in ("creation", "change") and
    registry.value : "UseLogonCredential" and
    registry.path : "*\\SYSTEM\\*ControlSet*\\Control\\SecurityProviders\\WDigest\\UseLogonCredential" and
    registry.data.strings : ("1", "0x00000001") and
    not (process.executable : "?:\\Windows\\System32\\svchost.exe" and user.id : "S-1-5-18")
'''

note = """## Triage and analysis

### Investigating Modification of WDigest Security Provider
#### Possible investigation steps

- Is the write to the active ControlSet, and does host context explain enablement?
  - Focus: `registry.path`, `registry.data.strings`, and `host.id`.
  - Implication: escalate when the active ControlSet is enabled, leaving cleartext credentials in LSASS for later logons; lower suspicion only for a recognized lab or legacy compatibility host with the exact expected pattern.

- Which process made the change, and does its identity fit?
  - Focus: `process.executable`, `process.command_line`, `process.code_signature.subject_name`, and `process.parent.command_line`. $investigate_0
  - Hint: pivot on `host.id` plus `process.entity_id`; if absent, bound to alert time and host.
  - Implication: escalate when the writer is unsigned, user-writable, renamed, script-launched, or has an unrelated parent; lower suspicion only when identity, parent, and registry outcome match one recognized validation activity. Trusted signer alone is not clearance.

- Does user and session context explain the change?
  - Focus: `user.id`, `user.domain`, `process.Ext.session_info.logon_type`, and `process.Ext.token.integrity_level_name`.
  - Implication: escalate when a normal user, unexpected admin, service account, remote session, or elevated token performs the write outside a recognized test path.

- Did the same process leave WDigest enabled or change adjacent security registry state?
  - Focus: registry events from the same `process.entity_id`: `registry.path`, `registry.value`, and `registry.data.strings`. $investigate_1
  - Hint: check for WDigest reversal and LSA or SecurityProviders changes before widening to the host.
  - Implication: escalate when WDigest stays enabled or the writer weakens LSA or security-provider settings; scope narrower when the write is isolated, promptly reversed, and no contradictory registry evidence remains.

- Does process activity after the write show credential-dumping preparation or execution?
  - Focus: child process events from `process.entity_id`: `process.executable` and `process.command_line`. $investigate_2
  - Implication: escalate when children show Mimikatz/sekurlsa, ProcDump or comsvcs.dll LSASS dumping, CrackMapExec, PowerShell remote execution, archives, or cleanup; absent follow-on evidence narrows extraction proof but does not clear enablement.

- Did any accounts authenticate while WDigest was enabled?
  - Focus: logon events after `@timestamp`: `event.code` 4624, `winlog.event_data.TargetUserName`, `winlog.event_data.AuthenticationPackageName`, `winlog.logon.type`, and `source.ip`. $investigate_3
  - Hint: expand until WDigest is disabled or the host is contained; for domain NTLM, search domain-controller 4776 records for the alert host as source workstation.
  - Implication: escalate credential exposure when successful WDigest or privileged logons occur after enablement. Missing authentication telemetry is unresolved, not benign.

- If local evidence is suspicious or unresolved, do related alerts change scope?
  - Focus: alerts for `user.id`, especially credential access, privilege escalation, or lateral movement. $investigate_4
  - Hint: compare host alerts for precursor access, LSASS-oriented follow-on, staging, or cleanup. $investigate_5
  - Implication: broaden when the same user or host shows adjacent post-compromise behavior; keep local when related alerts are quiet and local evidence fits one recognized workflow.

- Escalate when writer identity, session context, registry changes, unreverted WDigest exposure, follow-on activity, or related alerts indicate unauthorized credential-protection weakening; close only when those categories align with one confirmed activity and no contradictions remain; preserve and escalate when evidence is mixed or incomplete.

### False positive analysis

- Authorized security validation or legacy compatibility testing may enable WDigest. Confirm `process.executable`, `process.command_line`, `process.parent.command_line`, `user.id`, `host.id`, `registry.data.strings`, prompt reversion, and no contradictory registry or LSASS-oriented follow-on. If telemetry cannot prove the activity, leave unresolved.
- Build exceptions from the minimum confirmed workflow: `process.executable` or signer, `process.parent.command_line`, `user.id`, `host.id`, `registry.path`, and expected `registry.data.strings`. Avoid exceptions on `registry.path`, `process.name`, signer, or `host.id` alone.

### Response and remediation

- If confirmed benign, reverse any temporary containment, document the aligned workflow evidence, and create an exception only when the confirmed evidence pattern is expected to repeat and can be scoped narrowly.
- If suspicious but unconfirmed, preserve the alert, process tree, command lines, relevant registry events, related-alert results, and current WDigest state before containment. Apply reversible containment first, such as heightened monitoring or EDR network restrictions, and use host isolation only when follow-on dumping, unreverted exposure on a sensitive host, or broader compromise evidence justifies the operational impact.
- If confirmed malicious, preserve the writer `process.entity_id`, process tree, command lines, registry evidence, and current WDigest state; then isolate the host when the evidence supports it, restore WDigest to the disabled state, and eradicate only the scripts, binaries, registry changes, and persistence found during the investigation.
- After containment, review other registry changes by the same process and scope accounts that may have authenticated while WDigest was enabled through available authentication records; when those records are unavailable, treat credential exposure as unresolved and prioritize privileged, service, and lateral-movement-capable accounts for credential hygiene.
- Post-incident hardening: restrict who can modify WDigest and related LSA policy, validate baseline configuration through endpoint or policy management, retain registry and process telemetry for this host class, and document the confirmed workflow or malicious pattern for future analysts.
"""

setup = """## Setup

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

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

### Additional data sources

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

- [Microsoft Defender XDR](https://ela.st/m365-defender)
- [Sysmon Registry Events](https://ela.st/sysmon-event-reg-setup)
"""

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "host.id",
    "user.id",
    "process.code_signature.subject_name",
    "process.code_signature.trusted",
    "process.executable",
    "process.command_line",
    "process.entity_id",
    "process.parent.executable",
    "process.parent.command_line",
    "process.Ext.session_info.logon_type",
    "process.Ext.token.integrity_level_name",
    "registry.path",
    "registry.value",
    "registry.data.strings",
]

[transform]

[[transform.investigate]]
label = "Process events by WDigest writer"
description = ""
providers = [
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "Registry events by WDigest writer"
description = ""
providers = [
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "registry", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "Child process events by WDigest writer"
description = ""
providers = [
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "Logon events on the WDigest host"
description = ""
providers = [
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "event.code", queryType = "phrase", value = "4624", valueType = "string" }
  ]
]
relativeFrom = "now-24h"
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 = "T1003"
name = "OS Credential Dumping"
reference = "https://attack.mitre.org/techniques/T1003/"

[[rule.threat.technique.subtechnique]]
id = "T1003.001"
name = "LSASS Memory"
reference = "https://attack.mitre.org/techniques/T1003/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 = "T1112"
name = "Modify Registry"
reference = "https://attack.mitre.org/techniques/T1112/"

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

[metadata]
creation_date = "2024/09/27"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
This detection rule addresses multiple vulnerabilities in the CUPS printing system, including CVE-2024-47176,
CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177. Specifically, this rule detects network connections initiated by a
child processes of foomatic-rip. These flaws impact components like cups-browsed, libcupsfilters, libppd, and
foomatic-rip, allowing remote unauthenticated attackers to manipulate IPP URLs or inject malicious data through crafted
UDP packets or network spoofing. This can result in arbitrary command execution when a print job is initiated.
"""
from = "now-9m"
index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Network Connection by Cups or Foomatic-rip Child"
note = """## Triage and analysis

### Investigating Network Connection by Cups or Foomatic-rip Child

This rule identifies potential exploitation attempts of several vulnerabilities in the CUPS printing system (CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, CVE-2024-47177). These vulnerabilities allow attackers to send crafted IPP requests or manipulate UDP packets to execute arbitrary commands or modify printer configurations. Attackers can exploit these flaws to inject malicious data, leading to Remote Code Execution (RCE) on affected systems.

#### Possible Investigation Steps

- Investigate the incoming IPP requests or UDP packets targeting port 631.
- Examine the printer configurations on the system to determine if any unauthorized printers or URLs have been added.
- Investigate the process tree to check if any unexpected processes were triggered as a result of IPP activity. Review the executable files for legitimacy.
- Check for additional alerts related to the compromised system or user within the last 48 hours.
- Investigate network traffic logs for suspicious outbound connections to unrecognized domains or IP addresses.
- Check if any of the contacted domains or addresses are newly registered or have a suspicious reputation.
- Retrieve any scripts or executables dropped by the attack for further analysis in a private sandbox environment:
- Analyze potential malicious activity, including:
  - Attempts to communicate with external servers.
  - File access or creation of unauthorized executables.
  - Cron jobs, services, or other persistence mechanisms.

### Related Rules
- Cupsd or Foomatic-rip Shell Execution - 476267ff-e44f-476e-99c1-04c78cb3769d
- Printer User (lp) Shell Execution - f86cd31c-5c7e-4481-99d7-6875a3e31309
- Suspicious Execution from Foomatic-rip or Cupsd Parent - 986361cd-3dac-47fe-afa1-5c5dd89f2fb4
- File Creation by Cups or Foomatic-rip Child - b9b14be7-b7f4-4367-9934-81f07d2f63c4

### False Positive Analysis

- This activity is rarely legitimate. However, verify the context to rule out non-malicious printer configuration changes or legitimate IPP requests.

### Response and Remediation

- Initiate the incident response process based on the triage outcome.
- Isolate the compromised host to prevent further exploitation.
- If the investigation confirms malicious activity, search the environment for additional compromised hosts.
- Implement network segmentation or restrictions to contain the attack.
- Stop suspicious processes or services tied to CUPS exploitation.
- Block identified Indicators of Compromise (IoCs), including IP addresses, domains, or hashes of involved files.
- Review compromised systems for backdoors, such as reverse shells or persistence mechanisms like cron jobs.
- Investigate potential credential exposure on compromised systems and reset passwords for any affected accounts.
- Restore the original printer configurations or uninstall unauthorized printer entries.
- Perform a thorough antimalware scan to identify any lingering threats or artifacts from the attack.
- Investigate how the attacker gained initial access and address any weaknesses to prevent future exploitation.
- Use insights from the incident to improve detection and response times in future incidents (MTTD and MTTR).
"""
references = [
    "https://www.elastic.co/security-labs/cups-overflow",
    "https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/",
    "https://gist.github.com/stong/c8847ef27910ae344a7b5408d9840ee1",
    "https://github.com/RickdeJager/cupshax/blob/main/cupshax.py",
]
risk_score = 73
rule_id = "e80ee207-9505-49ab-8ca8-bc57d80e2cab"
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 = "high"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Use Case: Vulnerability",
    "Tactic: Command and Control",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
type = "eql"
query = '''
sequence by host.id with maxspan=10s
  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
   process.parent.name == "foomatic-rip" and
   process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")] by process.entity_id
  [network where host.os.type == "linux" and event.type == "start" and
   event.action == "connection_attempted"] by process.parent.entity_id
'''

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

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

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

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

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

[[rule.threat.technique]]
id = "T1203"
name = "Exploitation for Client Execution"
reference = "https://attack.mitre.org/techniques/T1203/"

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

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

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

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

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

[rule]
description = "Identifies the load of a networking library by calling directly the LdrLoadDLL windows API and from an unsigned module."
id = "1d11bfcd-b3dd-41f6-b770-fb7cca437019"
license = "Elastic License v2"
name = "Network Library Load via LdrLoadDLL"
os_list = ["windows"]
version = "1.0.5"

query = '''
sequence by process.entity_id with maxspan=1m
 [library where not dll.code_signature.status == "trusted" and 
  not user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20") and 
  not dll.path : ("?:\\Program Files\\*", "?:\\Program Files (x86)\\*", "?:\\Windows\\*") and 
  not process.executable : ("?:\\Program Files\\*", "?:\\Program Files (x86)\\*") and
  not dll.hash.sha256 in ("4bbe61307e8baa6e782c271361a41905f8ef2f7cdf62fa8fb4f4844860f3dc3d",
                          "5bcea56e9f25b53dfbf71d41f157647263a71754fb5c3b8b607c34c4d66d2e26",
                          "14da1fbca85ff2b8ac19ab63f4b7019614865ce8d87bce68100c97174b786ff5")] as event0
 [library where
   dll.name : ("ws2_32.dll", "winhttp.dll", "wininet.dll") and 
   _arraysearch(process.thread.Ext.call_stack, $entry, $entry.symbol_info : "*LdrLoadDLL*") and
    stringcontains~(process.thread.Ext.call_stack_summary, concat("ntdll.dll|", event0.dll.name)) and
   not _arraysearch(process.thread.Ext.call_stack, $entry,
                                                   $entry.symbol_info : ("*LoadLibrary*",
                                                                         "*LdrResolveDelayLoadedAPI*",
                                                                         "*hmpalert.dll!CVCCP*",
                                                                         "*LdrGetProcedureAddressEx*",
                                                                         "?:\\Program Files (x86)\\*.dll*",
                                                                         "?:\\Program Files\\*.dll*",
                                                                         "*KernelBase.dll!CreateProcess*")) and
   /* Managed Code, Cynet MemScanner, xSecuritas, Mcafee */
   not _arraysearch(process.thread.Ext.call_stack, $entry,
                    $entry.callsite_trailing_bytes :
                         ("*8945b4488bcce82c000000908b45b4488b55a8c6420c01488b55a8488b*",
                          "48898424e80300004883bc24e803000000750eff94247e030000898424f0030000eb30488d8c2430010000ff94248e03000048898424e80300004883bc24e803",
                          "8bd885db751eff55c88945f8eb168d8592fdffff50ff55d08bd885db7506ff55c88945f856ff55bc85db0f847601000080bd82fcffff0074508b45fc05a00000",
                          "488b55a8c6420c01833d8bbeb25f007406ff1593c7b25f8945b4488bcce82c000000908b45b4488b55a8c6420c01488b55a8488b8d70ffffff48894a10488d65", 
                          "2048894538488b4d1048c1e103488b7d38488b7550f3a44c8b4d284d8b49484c8b45284d8b4040488b5528488b5220488b4d28488b8988000000ff95a0000000",
                          "83c4209d61c38b1890906683fb1875158b580485db740e8b5b0c81fb33003200750331dbc331db4bc30000000000000000000000000000000000000000000000")) and
   not process.code_signature.subject_name : ("ZOHO Corporation Private Limited", "Sophos Ltd", "Electronic Arts, Inc.", "Epic Games Inc.")]
  [network where event.action == "connection_attempted" and 
   not 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")]
'''

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

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

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


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

[internal]
min_endpoint_version = "8.8.0"

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

[rule]
author = ["Elastic"]
description = """
Identifies the use of the Exchange PowerShell cmdlet, Set-CASMailbox, to add a new ActiveSync allowed device.
Adversaries may target user email to collect sensitive information.
"""
false_positives = ["Legitimate exchange system administration activity."]
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
]
language = "eql"
license = "Elastic License v2"
name = "New ActiveSyncAllowedDeviceID Added via PowerShell"
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 New ActiveSyncAllowedDeviceID Added via PowerShell

ActiveSync is a protocol enabling mobile devices to synchronize with Exchange mailboxes, crucial for accessing emails on-the-go. Adversaries may exploit the Exchange PowerShell cmdlet, Set-CASMailbox, to add unauthorized devices, gaining persistent access to sensitive email data. The detection rule identifies suspicious PowerShell activity by monitoring for specific command patterns, helping to flag potential unauthorized device additions and mitigate risks associated with account manipulation.

### Possible investigation steps

- Review the alert details to identify the specific process name (e.g., powershell.exe, pwsh.exe, powershell_ise.exe) and the command line arguments used, focusing on the presence of "Set-CASMailbox" and "ActiveSyncAllowedDeviceIDs".
- Examine the user account associated with the process execution to determine if the account has a history of legitimate administrative actions or if it might be compromised.
- Check the device ID added to the ActiveSyncAllowedDeviceIDs list to verify if it is recognized and authorized for use within the organization.
- Investigate the source IP address and host from which the PowerShell command was executed to assess if it aligns with expected administrative activity or if it originates from an unusual or suspicious location.
- Review recent email access logs for the user account to identify any unusual patterns or access from unfamiliar devices that could indicate unauthorized access.
- Correlate this event with other security alerts or logs from data sources like Microsoft Defender XDR or Sysmon to identify any related suspicious activities or patterns.

### False positive analysis

- Legitimate administrative tasks may trigger the rule when IT staff use PowerShell to configure or update ActiveSync settings for users. To manage this, create exceptions for known administrative accounts or specific maintenance windows.
- Automated scripts for device management that include the Set-CASMailbox cmdlet can cause false positives. Review and whitelist these scripts if they are verified as part of routine operations.
- Third-party applications that integrate with Exchange and modify ActiveSync settings might be flagged. Identify and exclude these applications if they are trusted and necessary for business operations.
- Regular audits of device additions by authorized personnel can help distinguish between legitimate and suspicious activities, allowing for more accurate exception handling.
- Consider the context of the activity, such as the time of day and the user account involved, to refine detection rules and reduce false positives.

### Response and remediation

- Immediately isolate the affected user account by disabling it to prevent further unauthorized access to the mailbox.
- Revoke the ActiveSync device access by removing the unauthorized device ID from the user's mailbox settings using the Exchange PowerShell cmdlet.
- Conduct a thorough review of the affected user's mailbox and account activity logs to identify any unauthorized access or data exfiltration attempts.
- Reset the password for the compromised user account and enforce multi-factor authentication (MFA) to enhance security.
- Notify the security team and relevant stakeholders about the incident for further investigation and potential escalation.
- Implement additional monitoring on the affected account and similar accounts for any unusual activity or further attempts to add unauthorized devices.
- Review and update the organization's security policies and procedures related to mobile device access and PowerShell usage to prevent recurrence."""
references = [
    "https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/",
    "https://docs.microsoft.com/en-us/powershell/module/exchange/set-casmailbox?view=exchange-ps",
]
risk_score = 47
rule_id = "ce64d965-6cb0-466d-b74f-8d2c76f47f05"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Execution",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Windows Security Event Logs",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and
  process.name: ("powershell.exe", "pwsh.exe", "powershell_ise.exe") and process.args : "Set-CASMailbox*ActiveSyncAllowedDeviceIDs*"
'''

setup = """## Setup

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

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

### Additional data sources

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

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


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

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

[[rule.threat.technique.subtechnique]]
id = "T1098.002"
name = "Additional Email Delegate Permissions"
reference = "https://attack.mitre.org/techniques/T1098/002/"

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

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

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

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

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

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

[[rule.threat.technique]]
id = "T1114"
name = "Email Collection"
reference = "https://attack.mitre.org/techniques/T1114/"

[[rule.threat.technique.subtechnique]]
id = "T1114.002"
name = "Remote Email Collection"
reference = "https://attack.mitre.org/techniques/T1114/002/"

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