Elastic rules: 1v

[rule]
description = """
Identifies attempts to enable the modification of Trusted Installer protected resources via PendingFileRename operation.
Malware may change this setting to hijack existing resources for execution and persistence.
"""
id = "6dad397a-7e26-4c5b-9a24-d19016f2ad03"
license = "Elastic License v2"
name = "AllowProtectedRenames Registry Modification"
os_list = ["windows"]
reference = [
    "https://qtechbabble.wordpress.com/2020/06/26/use-pendingfilerenameoperations-registry-key-to-automatically-delete-a-file-on-reboot/",
]
version = "1.0.6"

query = '''
registry where process.name != null and
 registry.value : "AllowProtectedRenames" and registry.data.strings : "1" and 
 not process.executable : ("?:\\Program Files\\*", "?:\\Program Files (86)\\*", "\\Device\\Mup\\lansweeper\\*$\\uninstall_flash_player.exe") and
 not (process.code_signature.status : "trusted" and not process.code_signature.subject_name : "Microsoft*")
'''

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 = "T1112"
name = "Modify Registry"
reference = "https://attack.mitre.org/techniques/T1112/"

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



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

[internal]
min_endpoint_version = "8.1.0"

[metadata]
creation_date = "2020/03/25"
integration = ["auditd_manager", "endpoint", "network_traffic"]
maturity = "production"
updated_date = "2026/07/27"
min_stack_version = "9.4.0"
min_stack_comments = "Use EA (Entity Analytics) fields"

[rule]
anomaly_threshold = 50
author = ["Elastic"]
description = """
Searches for rare processes running on multiple Linux hosts in an entire fleet or network. This reduces the detection of
false positives since automated maintenance processes usually only run occasionally on a single machine but are common
to all or many hosts in a fleet.
"""
false_positives = [
    """
    A newly installed program or one that runs rarely as part of a monthly or quarterly workflow could trigger this
    alert.
    """,
]
from = "now-45m"
interval = "15m"
license = "Elastic License v2"
machine_learning_job_id = ["v3_linux_anomalous_process_all_hosts_ea"]
name = "Anomalous Process For a Linux Population"
setup = """## Setup

This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
- Elastic Defend
- Auditd Manager
- Network Packet Capture

### Anomaly Detection Setup

Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).

### 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 to your 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/current/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).

### Auditd Manager Integration Setup
The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.
Auditd Manager provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system.

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

#### Rule Specific Setup Note
Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.
However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from.
- For this detection rule no additional audit rules are required.

### Network Packet Capture Integration Setup
The Network Packet Capture integration sniffs network packets on a host and dissects known protocols. Monitoring the network traffic is critical to gaining observability and securing your environment — ensuring high levels of performance and security. The Network Packet Capture integration captures the network traffic between your application servers, decodes common application layer protocols and records the interesting fields for each transaction.

#### The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:
- Go to the Kibana home page and click “Add integrations”.
- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it.
- Click “Add Network Packet Capture”.
- Configure the integration name and optionally add a description.
- Review optional and advanced settings accordingly.
- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable.
- Click “Save and Continue”.
- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/network_traffic).
"""
note = """## Triage and analysis

### Investigating Anomalous Process For a Linux Population

Searching for abnormal Linux processes is a good methodology to find potentially malicious activity within a network. Understanding what is commonly run within an environment and developing baselines for legitimate activity can help uncover potential malware and suspicious behaviors.

This rule uses a machine learning job to detect a Linux process that is rare and unusual for all of the monitored Linux hosts in your fleet.

#### Possible investigation steps

- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, and whether they are located in expected locations.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Consider the user as identified by the `user.name` field. Is this program part of an expected workflow for the user who ran this program on this host?
- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.
- Validate if the activity has a consistent cadence (for example, if it runs monthly or quarterly), as it could be part of a monthly or quarterly business process.
- Examine the arguments and working directory of the process. These may provide indications as to the source of the program or the nature of the tasks it is performing.

### False Positive Analysis

- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions.
- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need.

### Response and Remediation

- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved hosts to prevent further post-compromise behavior.
- If the triage identified malware, search the environment for additional compromised hosts.
  - Implement temporary network rules, procedures, and segmentation to contain the malware.
  - Stop suspicious processes.
  - Immediately block the identified indicators of compromise (IoCs).
  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that   attackers could use to reinfect the system.
- Remove and block malicious artifacts identified during triage.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""
references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
risk_score = 21
rule_id = "647fc812-7996-4795-8869-9c4ea595fe88"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Data Source: Elastic Defend",
    "Data Source: Auditd Manager",
    "Data Source: Network Packet Capture",
    "Use Case: Threat Detection",
    "Rule Type: ML",
    "Rule Type: Machine Learning",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
type = "machine_learning"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1543"
name = "Create or Modify System Process"
reference = "https://attack.mitre.org/techniques/T1543/"
[[rule.threat.technique.subtechnique]]
id = "T1543.003"
name = "Windows Service"
reference = "https://attack.mitre.org/techniques/T1543/003/"



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

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

[rule]
author = ["Elastic"]
description = """
Detects deletion of an AWS CloudTrail trail via DeleteTrail API. Removing trails is a high-risk action that destroys an
audit control plane and is frequently paired with other destructive or stealthy operations. Validate immediately and
restore compliant logging.
"""
false_positives = [
    """
    Trail deletions may be made by a system or network administrator. Verify whether the user identity, user agent,
    and/or hostname should be making changes in your environment. Trail 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 CloudTrail Log Deleted"
note = """## Triage and analysis

### Investigating AWS CloudTrail Log Deleted

AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. This rule identifies the deletion of an AWS log trail using the `DeleteTrail` API. Deleting a trail can eliminate visibility and is a strong indicator of defense evasion or sabotage.

#### Possible investigation steps
- **Actor & target**
  - Identify `aws.cloudtrail.user_identity.arn`, `user_agent.original`, `source.ip`.
  - Confirm which trail was deleted (name/ARN, multi-region/organization status) from `aws.cloudtrail.request_parameters`.
- **Blast radius**
  - Determine whether it was the only trail or if organization/multi-region coverage remains.
  - Review preceding `StopLogging` or `UpdateTrail` and subsequent high-risk actions (IAM, S3, KMS, EC2 exports).
- **Data preservation**
  - Verify S3 destinations and CloudWatch log groups for retained historical logs and file integrity validation.

### False positive analysis
- **Planned deletion**: Validate with tickets and decommissioning plans; ensure replacement/alternate trails exist.

### Response and remediation
- Recreate or re-enable compliant multi-region (or organization) trails immediately.
- Investigate the actor’s recent activity; rotate creds if compromise is suspected.
- Validate destination bucket policies, CMK policies, and event selectors for all active trails.
- Hardening: Restrict `cloudtrail:DeleteTrail` and enforce guardrails via AWS Config/SCPs; alert on future deletions.

### 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/awscloudtrail/latest/APIReference/API_DeleteTrail.html",
    "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudtrail/delete-trail.html",
]
risk_score = 47
rule_id = "7024e2a0-315d-4334-bb1a-441c593e16ab"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS Cloudtrail",
    "Use Case: Log Auditing",
    "Resources: Investigation Guide",
    "Tactic: Defense Evasion",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "cloudtrail.amazonaws.com"
    and event.action: "DeleteTrail"
    and event.outcome: "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.001"
name = "Disable or Modify Tools"
reference = "https://attack.mitre.org/techniques/T1562/001/"

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

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

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

[rule]
author = ["Elastic"]
description = """
An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by creating a
new set of credentials for an existing user. This rule looks for use of the IAM `CreateAccessKey` API operation to
create new programmatic access keys for another IAM user.
"""
false_positives = [
    """
    While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity
    should be using the IAM `CreateAccessKey` for the targeted user.
    """,
]
from = "now-6m"
language = "esql"
license = "Elastic License v2"
name = "AWS IAM User Created Access Keys For Another User"
note = """## Triage and analysis

### Investigating AWS IAM User Created Access Keys For Another User

AWS IAM access keys are long-term credentials that grant programmatic access to AWS resources. The `iam:CreateAccessKey` permission allows an IAM principal to generate new access keys for an existing IAM user.  
While this operation can be legitimate (for example, credential rotation), it can also be abused to establish persistence or privilege escalation if one user creates keys for another account without authorization.

This rule identifies `CreateAccessKey` API calls where the calling user (`aws.cloudtrail.user_identity.arn`) differs from the target user (`aws.cloudtrail.request_parameters.userName`), indicating one IAM identity creating credentials for another.

#### Possible investigation steps

- **Confirm both user identities and intent.**  
  Identify the calling user (who performed `CreateAccessKey`) and the target user (whose access key was created). Contact both account owners or application teams to confirm if this operation was expected.

- **Review CloudTrail event details.**  
  Check the following fields directly in the alert or corresponding CloudTrail record:  
  - `source.ip` — does it align with expected corporate ranges or known admin automation?  
  - `user_agent.original` — AWS Console, CLI, SDK, or custom client? Unexpected user agents (for example, non-SDK scripts) may indicate manual or unauthorized use.  
  - `source.geo` fields — verify the location details are expected for the identity.

- **Correlate with related IAM activity.**  
  In CloudTrail, search for subsequent or nearby events such as:  
  - `AttachUserPolicy`, `AttachGroupPolicy`, `UpdateAssumeRolePolicy`, or `CreateUser`.  
  These can indicate privilege escalation or lateral movement.  
  Also review whether the same principal recently performed `CreateAccessKey` for multiple users or repeated this action across accounts.

- **Inspect the new access key’s usage.**  
  Search for the newly created key ID (`aws.cloudtrail.response_elements.accessKey.accessKeyId`) in CloudTrail events following creation. Determine if it was used from unusual IP addresses, geographies, or services.  

- **Assess the risk of credential compromise.**  
  If you suspect malicious behavior, consider the following indicators:  
  - A non-admin user invoking `CreateAccessKey` for another user.  
  - Creation outside of normal automation pipelines.  
  - Use of the new key from a different IP or AWS account soon after creation.

- **Scope related activity.**  
  Review all activity from the calling user in the past 24–48 hours, focusing on `iam:*` API calls and resource creation events.  
  Correlate any S3, EC2, or KMS access attempts made using the new key to identify potential impact or data exposure.

### False positive analysis

- **Expected credential rotation.**  
  Some environments delegate credential rotation responsibilities to centralized automation or specific admin roles. Confirm if the calling user is authorized for such actions.  
- **Administrative workflows.**  
  Account provisioning systems may legitimately create keys on behalf of users. Check for standard tags, automation tools, or user agents that indicate managed operations.  
- **Service-linked roles or external IAM automation.**  
  Some AWS services create or rotate credentials automatically. Validate if the caller is a service-linked role or an automation IAM role used by a known deployment process.

### Response and remediation

**Immediate containment**
- Deactivate or delete the access key from the target IAM user immediately using the AWS Console, CLI, or API (`DeleteAccessKey`).  
- Rotate or reset credentials for both the calling and target users to eliminate possible compromise.  
- Restrict risky principals. Temporarily deny `iam:CreateAccessKey` and `iam:UpdateAccessKey` permissions for non-administrative roles while scoping the incident.  
- Enable or confirm MFA on both accounts involved, if not already enforced.

**Evidence preservation**
- Export all related `CreateAccessKey`, `DeleteAccessKey`, and `UpdateAccessKey` events within ±30 minutes of the alert to an evidence bucket.  
- Preserve CloudTrail, GuardDuty, and AWS Config data for the same period.  
- Record key event details: caller ARN, target user, `accessKeyId`, `source.ip`, `userAgent`, and timestamps.

**Scoping and investigation**
- Search CloudTrail for usage of the new access key ID after creation. Identify any API activity or data access tied to it.  
- Review IAM policy changes, group modifications, or new role assumptions around the same time.  
- Determine if any additional credentials or trust policy changes were made by the same actor.  
- Check for GuardDuty findings referencing anomalous credential usage or suspicious API behavior.

**Recovery and hardening**
- Remove or disable any unauthorized keys and re-enable only verified credentials.  
- Implement least-privilege IAM policies to limit which users can perform `CreateAccessKey`.  
- Monitor for future `CreateAccessKey` events where `userIdentity.arn != request_parameters.userName`.  
- Ensure Cloudtrail, GuardDuty and Security Hub are active across all regions.  
- Educate administrative users on secure key rotation processes and the risk of cross-user key creation.  

### Additional information

- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/):** Reference “Credential Compromise” and “IAM Misuse” procedures for containment and recovery.  
- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/):** See “Identity Access Review” and “Unauthorized Access Key Creation” for example response flows.  
- **AWS Documentation:** [Best practices for managing access keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html).  
- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).  
"""
references = [
    "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/#iamcreateaccesskey",
    "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence",
    "https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud",
    "https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html",
]
risk_score = 73
rule_id = "696015ef-718e-40ff-ac4a-cc2ba88dbeeb"
severity = "high"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS IAM",
    "Tactic: Persistence",
    "Tactic: Privilege Escalation",
    "Rule Type: ESQL",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-aws.cloudtrail-* metadata _id, _version, _index
| where data_stream.dataset == "aws.cloudtrail"
    and event.provider == "iam.amazonaws.com"
    and event.action == "CreateAccessKey"
    and event.outcome == "success"
    and user.name != user.target.name
    and not to_lower(user_agent.original) like "*terraform*"
    and not to_lower(user_agent.original) like "*pulumi*"
    and not to_lower(user_agent.original) like "*ansible*"
| keep
    @timestamp,
    cloud.account.id,
    cloud.region,
    event.provider,
    event.action,
    event.outcome,
    data_stream.dataset,
    user.name,
    source.address,
    source.ip,
    user.target.name,
    user_agent.original,
    aws.cloudtrail.request_parameters,
    aws.cloudtrail.response_elements,
    aws.cloudtrail.user_identity.arn,
    aws.cloudtrail.user_identity.type,
    aws.cloudtrail.user_identity.access_key_id,
    source.geo.*,
    _id,
    _version,
    _index
'''


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



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



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

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

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

[rule]
author = ["Elastic"]
description = """
Identifies the addition of an expiration lifecycle configuration to an Amazon S3 bucket. S3 lifecycle rules can
automatically delete or transition objects after a defined period. Adversaries can abuse them by configuring
auto-deletion of logs, forensic evidence, or sensitive objects to cover their tracks. This rule detects the use of the
PutBucketLifecycle or PutBucketLifecycleConfiguration APIs with Expiration parameters, which may indicate an attempt to
automate the removal of data to hinder investigation or maintain operational secrecy after malicious activity.
"""
event_category_override = "event.type"
false_positives = [
    """
    Legitimate administrators may add lifecycle expiration configurations to reduce storage costs or enforce retention
    policies. Confirm whether this change aligns with an approved data management policy or infrastructure-as-code
    workflow. Known lifecycle automation processes (e.g., cost-management tools, data-lifecycle governance jobs) can be
    safely excluded from alerting once verified.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail*"]
language = "eql"
license = "Elastic License v2"
name = "AWS S3 Bucket Expiration Lifecycle Configuration Added"
note = """## Triage and analysis

### Investigating AWS S3 Bucket Expiration Lifecycle Configuration Added

This rule detects when a lifecycle expiration policy is added to an S3 bucket via the `PutBucketLifecycle` or `PutBucketLifecycleConfiguration` API. Note: `PutBucketLifecycleConfiguration` is the newer supported API call, however both of these API calls show up as `PutBucketLifecycle` in Cloudtrail [ref](https://docs.aws.amazon.com/AmazonS3/latest/userguide/cloudtrail-logging-s3-info.html#cloudtrail-bucket-level-tracking).
Lifecycle expiration automatically deletes objects after a defined period (`Expiration:Days`), which can be leveraged by adversaries to erase logs, exfiltration evidence, or security artifacts before detection and response teams can review them.

Because deletion is automated and often silent, detecting the initial configuration event is critical.

#### Possible investigation steps

**Identify the actor and execution context**

- **Principal and Identity Type**:  
  Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id`.  
  Determine if the actor is an IAM user, role, or automation service account.  
  - Unusual: temporary credentials, federated roles, or previously inactive accounts.
- **Source Information**:  
  Review `source.ip`, `cloud.region`, and `user_agent.original` for unexpected geolocations, tool usage (CLI, SDK, automation service), or newly-observed hosts.
- **Timestamp correlation**:  
  Use `@timestamp` to check if this activity occurred during change windows or off-hours.

**Examine the lifecycle configuration details**
- Extract details from `aws.cloudtrail.request_parameters`:
  - `Expiration`: Number of days until deletion (e.g., `Days=1` indicates rapid expiry).  
  - `Prefix`: If limited to certain object paths (e.g., `/logs/`, `/tmp/`).  
  - `Status`: `Enabled` vs. `Disabled`.  
  - `ID` or rule name: May reveal purpose (“cleanup-test”, “delete-logs”).
- Determine the affected bucket from `aws.cloudtrail.resources.arn` or `aws.cloudtrail.resources.type`.  
  Cross-check the bucket’s purpose (e.g., log storage, data lake, analytics export, threat forensics).  
  - High-risk if the bucket contains audit, CloudTrail, or application logs.

**Correlate with related AWS activity**
Use AWS CloudTrail search or your SIEM to pivot for:
- **Prior suspicious activity**:
  - `DeleteObject`, `PutBucketPolicy`, `PutBucketAcl`, or `PutBucketLogging` changes to disable visibility.
  - IAM changes such as `AttachUserPolicy` or `CreateAccessKey` that may have enabled this modification.
- **Subsequent changes**:
  - `PutBucketLifecycle` events in other buckets (repeated pattern).  
  - Rapid `DeleteObject` events or object expiration confirmations.
- **Cross-account activity**:
  - Lifecycle rules followed by replication or cross-account copy events may indicate lateral exfiltration setup.

**Assess intent and risk**
- Verify if the actor has a valid business case for altering object retention.  
- If the bucket is used for security, compliance, or audit data, treat this as potential defense evasion.  
- Evaluate whether the lifecycle rule removes data faster than your retention policy permits.

### False positive analysis

- **Cost optimization**: Storage teams may automate lifecycle policies to reduce cost on infrequently accessed data.
- **Compliance enforcement**: Organizations implementing legal retention policies may set expiration for specific datasets.
- **Automation and IaC pipelines**: Terraform or CloudFormation templates often apply `PutBucketLifecycle` during resource deployment.

### Response and remediation

**Containment and validation**
**Revert or disable** the lifecycle configuration if it is unauthorized:  
   - Use the AWS Console or CLI (`delete-bucket-lifecycle` or `put-bucket-lifecycle-configuration --lifecycle-configuration Disabled`).
**Preserve evidence**:  
   - Copy existing objects (especially logs or forensic data) before they expire.  
   - Enable object versioning or replication to protect against loss.

**Investigation**
Review CloudTrail and S3 Access Logs for the same bucket:
   - Identify who and what performed previous deletions.
   - Determine whether any objects of investigative value have already been removed.
Search for other S3 buckets where similar lifecycle configurations were added in a short timeframe.

**Recovery and hardening**
Implement guardrails:
   - Use AWS Config rules like `s3-bucket-lifecycle-configuration-check` to monitor lifecycle changes.
   - Restrict `s3:PutLifecycleConfiguration` to specific administrative roles.
   - Enable [S3 Object Lock](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html) on log or evidence buckets to enforce immutability.
Enable Security Hub and GuardDuty findings for additional anomaly detection on S3 data management activity.

### Additional information

- **AWS Documentation**  
  - [S3 Lifecycle Configuration](https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-expire-general-considerations.html)  
  - [DeleteBucketLifecycle API Reference](https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketLifecycle.html)
- **AWS Playbooks**  
  - [Data Exposure and Exfiltration Response](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-PersonalDataBreach.md)  
  - [AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/main)
"""
references = [
    "https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-expire-general-considerations.html",
]
risk_score = 21
rule_id = "ff320c56-f8fa-11ee-8c44-f661ea17fbce"
severity = "low"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS S3",
    "Tactic: Defense Evasion",
    "Rule Type: Event Correlation (EQL)",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
info where data_stream.dataset == "aws.cloudtrail"
   and event.action == "PutBucketLifecycle"
   and event.outcome == "success"
   and stringContains(aws.cloudtrail.request_parameters, "Expiration=")
   and not user_agent.original like~ ("*Terraform*", "*Pulumi*")
'''


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

[[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.technique.subtechnique]]
id = "T1485.001"
name = "Lifecycle-Triggered Deletion"
reference = "https://attack.mitre.org/techniques/T1485/001/"



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

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

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

[rule]
author = ["Elastic"]
description = """
Identifies when server access logging is disabled for an Amazon S3 bucket. Server access logs provide a detailed record
of requests made to an S3 bucket. When server access logging is disabled for a bucket, it could indicate an adversary's
attempt to impair defenses by disabling logs that contain evidence of malicious activity.
"""
event_category_override = "event.type"
false_positives = [
    """
    Bucket logging may be disabled by a system or network administrator. Verify whether the user identity and/or user
    agent should be making changes in your environment. Bucket component deletions by unfamiliar users 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 = "eql"
license = "Elastic License v2"
name = "AWS S3 Bucket Server Access Logging Disabled"
note = """
## Triage and analysis

### Investigating AWS S3 Bucket Server Access Logging Disabled

This detection alerts when the server-access logging configuration for an S3 bucket is changed so that logging is disabled.  
Because detailed request logs are central to tracking object access, modifications here are significant from a visibility and forensics standpoint. They can signal that an adversary is preparing to act (exfiltrate, delete, or manipulate data) while minimizing audit evidence.

#### Possible investigation steps

**Identify the actor and context**
   - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id` to determine the who/what of the change.  
   - Inspect `user_agent.original`, `source.ip`, `@timestamp`, `cloud.account.id`, `cloud.region` for unusual or non-standard access patterns (e.g., new user, external IP, off-hours).
   - Check the bucket resource (via `aws.cloudtrail.resources.arn`, `aws.cloudtrail.resources.type`) to determine the bucket’s business role (e.g., logs, backups, sensitive data store).
        - Consider whether the bucket houses audit logs or access logs; if so, disabling logging is especially suspicious and a higher risk.

**Correlate with related activities**
   - Search for preceding or subsequent events by the same principal or for the same bucket:  
     - `DeleteObject`, `PutBucketAcl`, `PutBucketPolicy`, `RemoveBucketAccessPoint`, or other permissions changes (e.g., `PutBucketLifecycle`).  
     - `ListBucket`, `GetObject`, `CopyObject`, or large `GetObject` operations, especially from unusual IPs or cross-account.  
     - IAM changes in proximity: `AttachUserPolicy`, `CreateAccessKey`, `AssumeRole` by same principal or against the same principal.  
   - Review AWS Config or Audit logs to see if the bucket’s logging was previously enabled and how long it has been disabled.

**Evaluate intent and risk**
   - If the bucket was being used to collect access logs or audit data, disabling logging significantly degrades forensic capability.  
   - Determine whether the actor has a legitimate business reason for modifying logging (ticket, change request, known automation).  
   - If not justified, treat this as a high-priority visibility compromise and proceed through escalation.

### False positive analysis

- Storage teams may disable logging temporarily during migration or cost-optimisation exercises.  
- Test or development buckets may routinely toggle logging for experimentation—document such buckets and roles.  
- Trusted automation (tagged, known user-agent, internal IPs) may adjust logging. Consider allow-listing such automation while preserving watch-points for changes to high-sensitivity buckets.

### Response and remediation

**Contain & restore visibility**
   - Immediately re-enable server‐access logging for the affected bucket (ensure `LoggingEnabled=true` and correct `TargetBucket/Prefix`).  
   - If you suspect activity while logging was disabled, preserve any remaining object versions, cross-account access logs, or S3 Inventory data.  

**Investigate scope and impact**
   - Use CloudTrail Lake or Athena to query access to the bucket and objects for the timeframe when logging was disabled.  
   - Identify external IP addresses, unusual principals, or rapid object transfers or deletions.

**Recover & harden**
   - Apply bucket-policy or SCP restrictions to prevent unauthorized modifications of `PutBucketLogging` for audit/logging buckets.  
   - Enable AWS Config rule (e.g., `cloudtrail-s3-bucket-access-logging`) to alert if logging is disabled.  
   - Ensure logging target buckets are configured with retention, versioning, and immutability (S3 Object Lock) to prevent tampering.

**Improve & monitor**
   - Update your incident response playbook to include this scenario (see AWS IR + Customer Playbook Framework).  
   - Educate stakeholders (storage, DevOps, security) that any change to logging configuration on buckets — especially audit/log buckets should be treated as a security event and ticketed.

### Additional information

- AWS documentation on [S3 Server Access Logging](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerLogs.html)  
- [AWS Incident Response Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/tree/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks)  
- [AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)  
"""
references = [
    "https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketLogging.html",
    "https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html",
]
risk_score = 73
rule_id = "a6788d4b-b241-4bf0-8986-a3b4315c5b70"
severity = "high"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS S3",
    "Tactic: Defense Evasion",
    "Rule Type: Event Correlation (EQL)",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
info where data_stream.dataset == "aws.cloudtrail"
   and event.provider == "s3.amazonaws.com"
   and event.action == "PutBucketLogging"
   and event.outcome == "success"
   and not stringContains(aws.cloudtrail.request_parameters, "LoggingEnabled")
   and not user_agent.original like~ ("*Terraform*", "*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.008"
name = "Disable or Modify Cloud Logs"
reference = "https://attack.mitre.org/techniques/T1562/008/"



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

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

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

[rule]
author = ["Elastic"]
description = """
Identifies when an Azure Automation webhook is created. Azure Automation runbooks can be configured to execute via a
webhook. A webhook uses a custom URL passed to Azure Automation along with a data payload specific to the runbook. An
adversary may create a webhook in order to trigger a runbook that contains malicious code.
"""
from = "now-9m"
index = ["logs-azure.activitylogs-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure Automation Webhook Created"
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 Automation Webhook Created

Azure Automation webhooks enable automated task execution via HTTP requests, integrating with external systems. Adversaries may exploit this by creating webhooks to trigger runbooks with harmful scripts, maintaining persistence. The detection rule identifies webhook creation events, focusing on specific operation names and successful outcomes, to flag potential misuse in cloud environments.

### Possible investigation steps

- Review the Azure activity logs to identify the user or service principal that initiated the webhook creation by examining the `event.dataset` and `azure.activitylogs.operation_name` fields.
- Check the associated runbook linked to the created webhook to determine its purpose and inspect its content for any potentially malicious scripts or commands.
- Investigate the source IP address and location from which the webhook creation request originated to identify any unusual or unauthorized access patterns.
- Verify the legitimacy of the webhook by contacting the owner of the Azure Automation account or the relevant team to confirm if the webhook creation was expected and authorized.
- Assess the broader context of the activity by reviewing recent changes or activities in the Azure Automation account to identify any other suspicious actions or configurations.

### False positive analysis

- Routine webhook creations for legitimate automation tasks can trigger false positives. Review the context of the webhook creation, such as the associated runbook and its purpose, to determine if it aligns with expected operations.
- Frequent webhook creations by trusted users or service accounts may not indicate malicious activity. Consider creating exceptions for these users or accounts to reduce noise in alerts.
- Automated deployment processes that involve creating webhooks as part of their workflow can be mistaken for suspicious activity. Document these processes and exclude them from triggering alerts if they are verified as safe.
- Integration with third-party services that require webhook creation might generate alerts. Verify these integrations and whitelist them if they are part of approved business operations.
- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule.

### Response and remediation

- Immediately disable the suspicious webhook to prevent further execution of potentially harmful runbooks.
- Review the runbook associated with the webhook for any unauthorized or malicious scripts and remove or quarantine any identified threats.
- Conduct a thorough audit of recent changes in the Azure Automation account to identify any unauthorized access or modifications.
- Revoke any compromised credentials and enforce multi-factor authentication (MFA) for all accounts with access to Azure Automation.
- Notify the security team and relevant stakeholders about the incident for further investigation and to ensure awareness of potential threats.
- Implement enhanced monitoring and alerting for webhook creation and execution activities to detect similar threats in the future.
- Document the incident, including actions taken and lessons learned, to improve response strategies and prevent recurrence.

## Setup

The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://powerzure.readthedocs.io/en/latest/Functions/operational.html#create-backdoor",
    "https://github.com/hausec/PowerZure",
    "https://posts.specterops.io/attacking-azure-azure-ad-and-introducing-powerzure-ca70b330511a",
    "https://www.ciraltos.com/webhooks-and-azure-automation-runbooks/",
]
risk_score = 21
rule_id = "e9ff9c1c-fe36-4d0d-b3fd-9e0bf4853a62"
severity = "low"
tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Persistence", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:azure.activitylogs and
  azure.activitylogs.operation_name:
    (
      "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WEBHOOKS/ACTION" or
      "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WEBHOOKS/WRITE"
    ) and
  event.outcome:(Success or success)
'''

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

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

[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1608"
name = "Stage Capabilities"
reference = "https://attack.mitre.org/techniques/T1608/"

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

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

[rule]
author = ["Elastic"]
description = """
Detects execution of bpftool commands used to detach eBPF programs or links, or to delete or modify eBPF maps. These
actions can disable, alter, or interfere with kernel-level instrumentation and enforcement mechanisms implemented
through eBPF. In environments relying on eBPF-based networking, observability, or security controls, unexpected
use of these operations may indicate defense evasion or runtime tampering.
"""
from = "now-9m"
index = [
    "auditbeat-*",
    "endgame-*",
    "logs-auditd_manager.auditd-*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-crowdstrike.fdr*",
]
language = "eql"
license = "Elastic License v2"
name = "BPF Program Tampering via bpftool"
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 BPF Program Tampering via bpftool

This rule detects bpftool executions that detach eBPF programs/links or delete/update eBPF maps, actions that can silently disable kernel-level visibility and enforcement built on eBPF. Attackers use these operations to evade detection or weaken runtime controls by removing loaded probes or rewriting map contents that drive policy decisions. A common pattern is running bpftool to detach a program from a hook or detach a link shortly before other suspicious activity.

### Possible investigation steps

- Pull the full bpftool command line and correlate it with the invoking user, session (TTY/SSH), parent process chain, and any preceding privilege escalation to determine whether it was interactive admin work or automated tampering.  
- Capture current eBPF state (`bpftool prog show`, `bpftool link show`, `bpftool map show -j`) and compare with recent snapshots/logs to identify which program/link/map changed and what controls (sensor, CNI, LSM, XDP/TC) may have been impacted.  
- Identify the affected attachment point by mapping the detached program/link ID to its hook (e.g., tc/xdp/cgroup/tracepoint/kprobe) and validate operational impact by checking for missing telemetry, policy gaps, or network behavior changes around the event time.  
- Review audit/system logs and package history for installation or recent execution of bpftool, kernel/debug tooling, or custom eBPF loaders, and look for nearby suspicious binaries/scripts that could be orchestrating repeated detach/update actions.  
- If malicious activity is suspected, preserve artifacts by exporting bpftool JSON output and relevant `/sys/fs/bpf` entries, then hunt for follow-on persistence or rootkit-like behavior (new eBPF loads, altered maps, hidden processes, unexpected kernel module activity) on the host.

### False positive analysis

- A system administrator or SRE running bpftool during incident response or troubleshooting may detach a program/link or update/delete a map to temporarily disable an eBPF hook and validate whether it is causing network drops, performance regressions, or incorrect enforcement.
- A maintenance workflow during kernel, CNI, or eBPF policy rollouts may use bpftool to detach and replace existing attachments or refresh map entries as part of a controlled upgrade/rollback, especially when reloading pinned objects under `/sys/fs/bpf`.

### Response and remediation

- Contain by isolating the host from the network or restricting outbound access while preserving access for forensics if bpftool detach/map operations are unexpected or coincide with loss of eBPF-based enforcement/telemetry.  
- Eradicate by stopping and removing the controlling process/script (inspect the bpftool parent chain and cron/systemd units), revoking the initiating account’s sudo/root access, and deleting any unauthorized pinned objects under `/sys/fs/bpf` after exporting them for evidence.  
- Recover by reloading the approved eBPF components (agent/CNI/LSM/XDP/TC) from trusted packages or images, reattaching required programs/links, and restoring known-good map contents from backups or redeploying policy to repopulate maps.  
- Escalate to incident response and platform owners immediately if repeated bpftool tampering persists after containment, you find unknown pinned maps/programs with suspicious names/owners, or multiple hosts show simultaneous detach/update activity.  
- Harden by limiting bpftool availability (remove from production images where not needed), enforcing least-privilege on CAP_BPF/CAP_SYS_ADMIN and sudoers, and adding immutable monitoring of `/usr/sbin/bpftool` and `/sys/fs/bpf` plus periodic snapshots of `bpftool prog/link/map show` for drift detection."""
references = [
    "https://manpages.ubuntu.com/manpages/jammy/man8/bpftool-prog.8.html",
    "https://manpages.ubuntu.com/manpages/noble/man8/bpftool-map.8.html",
    "https://man.archlinux.org/man/bpftool-link.8.en",
]
risk_score = 47
rule_id = "1b65429e-bd92-44c0-aff8-e8065869d860"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Threat: Rootkit",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Auditd Manager",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
process.name == "bpftool" and (
  (process.args == "prog" and process.args == "detach") or
  (process.args == "map" and process.args in ("delete", "update")) or
  (process.args == "link" and process.args == "detach")
)
'''

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

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

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

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

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

[metadata]
creation_date = "2020/08/17"
integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2026/05/03"

[rule]
author = ["Elastic"]
description = """
Detects when the Console Window Host (conhost.exe) process is spawned by a suspicious parent process, which could be
indicative of code injection.
"""
from = "now-9m"
index = [
    "winlogbeat-*",
    "logs-endpoint.events.process-*",
    "logs-windows.sysmon_operational-*",
    "endgame-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Conhost Spawned By Suspicious Parent Process"
references = [
    "https://cloud.google.com/blog/topics/threat-intelligence/monitoring-windows-console-activity-part-one",
]
risk_score = 73
rule_id = "05b358de-aa6d-4f6c-89e6-78f74018b43b"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Resources: Investigation Guide",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: Microsoft Defender XDR",
    "Data Source: SentinelOne",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and
  process.name : "conhost.exe" and
  process.parent.name : ("lsass.exe", "services.exe", "smss.exe", "winlogon.exe", "explorer.exe", "dllhost.exe", "rundll32.exe",
                         "regsvr32.exe", "userinit.exe", "wininit.exe", "spoolsv.exe", "ctfmon.exe") and
  not (process.parent.name : "rundll32.exe" and
       process.parent.args : ("?:\\Windows\\Installer\\MSI*.tmp,zzzzInvokeManagedCustomActionOutOfProc",
                              "?:\\WINDOWS\\system32\\PcaSvc.dll,PcaPatchSdbTask",
                              "?:\\WINDOWS\\system32\\davclnt.dll,DavSetCookie"))
'''

note = """## Triage and analysis

### Investigating Conhost Spawned By Suspicious Parent Process

#### Possible investigation steps

- Is the alerting "conhost.exe" the native console host, and which parent requested the console?
  - Why: Windows creates "conhost.exe" for console clients; service, COM, logon, or shell parents rarely need direct console allocation.
  - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.parent.executable`, and `process.parent.command_line`.
  - Implication: escalate if "conhost.exe" is renamed, outside the Windows directory, mismatched to its PE name, not Microsoft-signed, or if parent path and command line contradict its name; lower only when native child and parent identity fit one exact MSI, compatibility, or WebDAV helper action explaining direct parentage.

- Does the parent identity, lineage, and session fit a legitimate console allocation path?
  - Focus: `process.parent.executable`, `process.parent.command_line`, `process.parent.code_signature.subject_name`, `process.Ext.ancestry`, and `process.Ext.session_info.logon_type`.
  - Implication: escalate when system/logon, COM/LOLBin, or shell/input parents run from unexpected paths, have unfamiliar signers, appear in unexpected ancestry, or allocate a console in a mismatched session; lower when signed parent command line and session fit one bounded MSI custom action, Program Compatibility Assistant, or WebDAV workflow.

- Did the same parent launch a shell, script host, LOLBin, or payload around the alert?
  - Focus: same-host child process events by `process.parent.entity_id`; if absent, use `host.id`, `process.parent.pid`, and a tight alert-time window, then read child `process.executable`, `process.command_line`, and signer. $investigate_2
  - Hint: if clean but parent identity remains suspicious, check for pre-existing console or shell processes in the same `host.id` and session before closure.
  - Implication: escalate when the parent starts shells, script hosts, downloaders, task/service tools, or unsigned payloads; lower only when "conhost.exe" is the lone unusual child and earlier evidence proves an exact bounded parent workflow, but do not close on this alone because attackers can reuse an existing console or shell.

- If file or registry telemetry is available, did the same parent stage artifacts or change configuration?
  - Focus: match parent `process.parent.entity_id` to actor `process.entity_id` on `host.id`; if absent, match parent/actor PID in a tight alert window, then read `file.path`. $investigate_3
  - Hint: use the same joins for `registry.path`. $investigate_4 Missing file or registry telemetry is unresolved, not benign.
  - Implication: escalate when the parent writes executables or scripts, stages console clients, or changes persistence or security configuration; absent optional artifacts lower corroboration only and do not close.

- If DNS or network telemetry is available, did the same parent contact staging, remote-control, or lateral destinations?
  - Focus: match parent `process.parent.entity_id` to actor `process.entity_id` on `host.id`; if absent, match parent/actor PID in a tight alert window, then read DNS "lookup_result" events (`dns.question.name`, `dns.resolved_ip`) separately from connections (`destination.ip`). $investigate_5
  - Hint: missing DNS or network telemetry is unresolved, not benign; correlate `dns.resolved_ip` to `destination.ip` before treating a domain as contacted.
  - Implication: escalate when the parent reaches public or internal destinations unrelated to the workflow, WebDAV/SMB destinations, or unexpected internal systems; lower only when destinations fit the same MSI, Program Compatibility Assistant, or WebDAV workflow proven by process evidence.

- If the parent path, child execution, artifacts, or destinations remain suspicious or unexplained, do related alerts change scope or urgency?
  - Focus: recent `host.id` alerts, especially process injection, indirect execution, suspicious shell, credential, or C2 activity. $investigate_0
  - Hint: review the same `user.id` only when the local evidence suggests the operator or session may have moved to other systems. $investigate_1
  - Implication: broaden scope when the same host or user has related injection, shell, credential, or C2 alerts; keep the case local when isolated and earlier process evidence fits one exact recognized workflow.

- Escalate for masqueraded parent, unexpected ancestry, unexplained console allocation, suspicious follow-on execution, staging, or remote-control corroboration; close only when native "conhost.exe" identity, parent identity/lineage, session, child processes, optional artifact or destination evidence, and related alerts align with one recognized installer, compatibility, or WebDAV workflow with no contradictions; if mixed or incomplete, preserve evidence and escalate.

### False positive analysis

- Installer repair, MSI custom actions, Program Compatibility Assistant activity, and WebDAV helpers can allocate "conhost.exe" from signed parents. Confirm parent path/command/signer, `process.executable`, `user.id`, and `host.id` describe one exact workflow, same-parent children show no shells, script hosts, LOLBins, or payloads, and optional file, registry, DNS, or network telemetry does not contradict it. Use change records, inventories, or owner confirmation only after telemetry fits.
- Without organizational context, telemetry-only confirmation must prove the current event fits that workflow. Historical alerts corroborate only when the same parent path, signer, command line, child, user/host, and bounded child pattern recur without contradictions; do not close on recurrence while parentage or follow-on execution remains unexplained.
- Before an exception, validate the minimum stable pattern: parent executable, command line, signer, child executable, `user.id`, and `host.id`. Avoid exceptions on "conhost.exe", parent name, or broad signers alone.

### Response and remediation

- If confirmed benign, reverse temporary containment, document native child identity, parent path/signer/command, session, `user.id`, `host.id`, and corroboration, and create exceptions only for the recurring minimum pattern above.
- If suspicious but unconfirmed, preserve the alert export, parent/child timeline, entity IDs, command lines, artifact/destination indicators, and owner/change evidence before containment. Apply reversible controls first: temporary destination blocking or heightened `host.id` / `user.id` monitoring; disable a task, service, or startup item only after identifying it as malicious. Escalate to isolation or account action only when follow-on execution, persistence, remote control, or credential abuse is confirmed and the asset can tolerate interruption.
- If confirmed malicious, isolate the host when unauthorized parent execution, payload launch, persistence, or remote control is confirmed, after weighing host role. Record parent/payload process IDs and command lines before suspending or terminating processes, then block confirmed malicious destinations, hashes, or domains.
- Eradicate only malicious parent/payload artifacts and configuration changes. Review other hosts/users for the same parent path, command line, child executable, artifact, or destination before deleting payloads, removing persistence, restoring settings, or closing the execution vector.
- Post-incident hardening: tighten the exposed MSI, Program Compatibility Assistant, or WebDAV workflow, and record variants such as existing-console reuse, injected "explorer.exe", or service-host console abuse.
"""

setup = """## Setup

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

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

### Additional data sources

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

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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "host.id",
    "user.id",
    "process.entity_id",
    "process.pid",
    "process.executable",
    "process.pe.original_file_name",
    "process.code_signature.subject_name",
    "process.code_signature.trusted",
    "process.parent.entity_id",
    "process.parent.pid",
    "process.parent.executable",
    "process.parent.command_line",
    "process.parent.code_signature.subject_name",
    "process.parent.code_signature.trusted",
]

[transform]

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

[[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 = "Process starts from the same suspicious parent"
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.parent.entity_id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
    { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" }
  ],
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.parent.pid", queryType = "phrase", value = "{{process.parent.pid}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
    { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "File events from the same suspicious parent"
description = ""
providers = [
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.parent.entity_id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" }
  ],
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.pid", queryType = "phrase", value = "{{process.parent.pid}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

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

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

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

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

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

[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 = "T1055"
name = "Process Injection"
reference = "https://attack.mitre.org/techniques/T1055/"

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

[rule]
description = """
Identifies the modification of DLL Control Panel Items registry. Adversaries may load a malicious DLL when Control Panel
is executed via setting the CPLs subkey to the DLL path.
"""
id = "340bdcad-187f-4ccb-b84e-34ee70844d78"
license = "Elastic License v2"
name = "DLL Control Panel Items Registry Modification"
os_list = ["windows"]
reference = ["https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/hh127454(v=vs.85)"]
version = "1.0.26"

query = '''
registry where
 registry.path :
      ("HKEY_USERS\\S-1-5-*\\Software\\Microsoft\\Windows\\CurrentVersion\\Control Panel\\CPLs\\*",
       "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Control Panel\\CPLs\\*") and
  process.executable != null and registry.data.strings != null and not registry.data.type : "REG_DWORD" and
  not (process.executable :
              ("?:\\Windows\\System32\\svchost.exe",
               "?:\\Windows\\System32\\DriverStore\\FileRepository\\*.exe",
               "?:\\Windows\\System32\\drvinst.exe",
               "?:\\Windows\\System32\\msiexec.exe") and user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20")) and
  not (process.code_signature.subject_name : "Wacom Co., Ltd." and process.code_signature.trusted == true) and
  not registry.data.strings : ("C:\\Program Files\\*", "C:\\Program Files (x86)\\*")
'''

min_endpoint_version = "8.0.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 = "T1218"
name = "System Binary Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1218/"
[[threat.technique.subtechnique]]
id = "T1218.002"
name = "Control Panel"
reference = "https://attack.mitre.org/techniques/T1218/002/"



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

[internal]
min_endpoint_version = "8.0.0"

[metadata]
creation_date = "2023/03/30"
integration = ["google_workspace"]
maturity = "production"
updated_date = "2026/06/15"

[rule]
author = ["Elastic"]
description = """
Detects the first time a user authorizes a third-party Google OAuth application that requests identity or sign-in
scopes. Adversaries may abuse compromised credentials or phishing-linked consent flows to register novel OAuth clients,
obtain refresh tokens, and authenticate as valid users while evading password-only detections.
"""
false_positives = [
    """
    Developers may leverage third-party applications for legitimate purposes in Google Workspace such as for
    administrative tasks.
    """,
]
from = "now-130m"
index = ["logs-google_workspace.token-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "First Time Seen Google Workspace OAuth Login from Third-Party Application"
note = """## Triage and analysis

### Investigating First Time Seen Google Workspace OAuth Login from Third-Party Application

Threat actors may trick users into authorizing adversary-controlled OAuth applications after credential theft, AiTM
relay, or spearphishing. A successful `authorize` grant issues tokens the application can reuse to act on behalf of the
user. Novel third-party client IDs are a strong signal as malicious consent often appears as a first-time application in the tenant.

This rule uses `new_terms` to flag the first appearance of a `google_workspace.token.client.id` when
a user grants at least one identity or sign-in scope in `google_workspace.token.scope.value` (for example `openid`,
`userinfo.email`, `userinfo.profile`, or `OAuthLogin`).

### Possible investigation steps

- Identify the user who authorized the application by reviewing `user.email` or `user.name`, and note `source.ip` and `event.ingested` if present in the alert.
- Identify the application by reviewing `google_workspace.token.app_name` and `google_workspace.token.client.id`.
- Review granted scopes in `google_workspace.token.scope.value` to determine whether the app received identity-only access or additional permissions (for example calendar, drive, or mail scopes on the same grant).
- Determine whether the authorization is expected and authorized:
  - If `source.ip` or timing is unusual for the user, treat the alert as higher priority until proven benign.'

- Search Kibana for related activity:
  - Find prior authorizations for the same client in the org:
    ```
    data_stream.dataset: "google_workspace.token" and event.action: "authorize" and google_workspace.token.client.id: "<CLIENT_ID>"
    ```
  - Correlate with sign-in anomalies for the same user:
    ```
    data_stream.dataset: "google_workspace.login" and user.email: "<USER_EMAIL>"
    ```
  - Scope for other OAuth or admin changes from the same `user.email` within the last 48 hours.

### False positive analysis

- Internal development or QA OAuth clients may appear as new `client.id` values during testing; coordinate with engineering teams and exclude known test clients if needed.
- Some vendors rotate OAuth client IDs during major upgrades, which can look like a new application, confirm with the vendor or IT owner before closing as benign.

### Response and remediation

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

## Setup

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

### Important Information Regarding Google Workspace Event Lag Times
- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs.
- This rule is configured to run every 10 minutes with a lookback time of 130 minutes.
- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m).
- See the following references for further information:
  - https://support.google.com/a/answer/7061566"""
references = [
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two",
    "https://developers.google.com/apps-script/guides/bound",
    "https://developers.google.com/identity/protocols/oauth2",
]
risk_score = 47
rule_id = "21bafdf0-cf17-11ed-bd57-f661ea17fbcc"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: Google Workspace",
    "Tactic: Defense Evasion",
    "Tactic: Initial Access",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "google_workspace.token"
  and event.action: "authorize"
  and google_workspace.token.scope.value: (*openid* or *userinfo.email* or *userinfo.profile* or *Login*)
  and google_workspace.token.client.id: *apps.googleusercontent.com
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1550"
name = "Use Alternate Authentication Material"
reference = "https://attack.mitre.org/techniques/T1550/"
[[rule.threat.technique.subtechnique]]
id = "T1550.001"
name = "Application Access Token"
reference = "https://attack.mitre.org/techniques/T1550/001/"



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



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



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

[rule.investigation_fields]
field_names = [
    "user.name",
    "user.email",
    "source.ip",
    "user.domain",
    "event.action",
    "google_workspace.token.app_name",
    "google_workspace.token.client.type",
    "google_workspace.token.client.id",
    "google_workspace.token.scope.value",
]

[rule.new_terms]
field = "new_terms_fields"
value = ["google_workspace.token.client.id"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-15d"

[metadata]
bypass_bbr_timing = true
creation_date = "2026/02/20"
integration = ["o365"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Identifies Microsoft 365 email quarantine, hygiene, and mail submission events. These signals indicate blocked threats,
spam filtering actions, and user-reported suspicious emails. While these represent blocked or mitigated threats, they
provide valuable telemetry for understanding attempted attacks and attack patterns. This building block rule generates
security events for correlation, threat hunting, and telemetry collection.
"""
from = "now-9m"
index = ["logs-o365.audit-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "M365 Quarantine and Hygiene Signal"
references = [
    "https://learn.microsoft.com/en-us/defender-office-365/quarantine-about",
    "https://learn.microsoft.com/en-us/defender-office-365/outbound-spam-protection-about",
    "https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-schema#enum-auditlogrecordtype---type-edmint32",
]
risk_score = 21
rule_id = "4bae6c34-57be-403a-a556-e48f9ecef0b7"
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 = "low"
tags = [
    "Domain: Cloud",
    "Domain: SaaS",
    "Data Source: Microsoft 365",
    "Data Source: Microsoft 365 Audit Logs",
    "Data Source: Microsoft Defender for Office 365",
    "Use Case: Threat Detection",
    "Use Case: Blocked Threat Tracking",
    "Tactic: Initial Access",
    "Rule Type: BBR",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.dataset:o365.audit and event.code:(Quarantine or HygieneEvent or MailSubmission)
'''


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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1566.002"
name = "Spearphishing Link"
reference = "https://attack.mitre.org/techniques/T1566/002/"

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

[metadata]
creation_date = "2024/03/24"
integration = ["endpoint"]
maturity = "production"
promotion = true
updated_date = "2025/07/02"

[rule]
author = ["Elastic"]
description = """
Generates a detection alert each time an Elastic Defend alert for malicious files is received. Enabling this rule allows
you to immediately begin investigating your Endpoint malicious file alerts. This rule identifies Elastic Defend
malicious file preventions only, and does not include detection only alerts.
"""
enabled = false
from = "now-2m"
index = ["logs-endpoint.alerts-*"]
interval = "1m"
language = "kuery"
license = "Elastic License v2"
max_signals = 1000
name = "Malicious File - Prevented - Elastic Defend"
note = """## Triage and analysis

### Investigating Malicious File - Prevented - Elastic Defend

Elastic Endpoint malware protection leverages a combination of supervised machine learning (ML) models (PE, MachO) and yara signatures. Our ML models are trained on hundreds of millions of executables and model updates are released approximately monthly. Our yara signatures are created with automated signature creation technologies built in-house along with  hand-written rules by our threat researchers.

Files are scanned on write or deletion, process executables are scanned on executions and libraries are scanned on load. You can differentiate these types by looking at the `event.action` field in the alert. It can be execution, `load`, `creation`, `modification`, or `deletion`. Scanning files written to disk is best effort, while execution or load scanning is done ‘in-line’ for true prevention.

### Possible investigation steps

- For machine learning (ML) malware alerts the `file.Ext.malware_classification.score` and `file.Ext.malware_classification.version` fields indicate which model version was used to classify the file and the classification score (0 to 1).
- For malware signature hits, `threat_name` is an important field which will guide the user on what malware family the sample belongs to.
- For Yara matches, Malware alerts do provide the specific binary content identified by the yara rule in the alert metadata (it is base64 encoded and stored in the `matches` field).
- A file can also hit on multiple Yara signatures. In the alert metadata, the `primary` signature (`malware_signature.primary`) will be whichever we determine to have the highest severity.
- Malicious file alerts for files in download directories or written by browsers, office applications, script interpreters or other lolbins are especially correlated with malicious activity.
- Particular attention should be paid to files located in suspicious directories like `Public` folder, `Downloads`, `Temp` and `ProgramData`.
- Verify if the file is signed or not using the `file.Ext.code_signature` field. Even if the file is signed with a valid certificate verify the global prevalance of that signed in your environment.
- Verify the malicious file timestamp metadata using `file.created`, `file.mtime` and `file.accessed` to asses exactly if it's an old or new infection.
- Investigate the activity of the process that created, modified or loaded the malicious file (parent process tree, process.command_line, child processes, network, registry and files events).
- Assess whether this file is prevalent in the environment by looking for similar occurrences across hosts by `file.hash.sha256` or by `file.name` patterns.
- Verify the activity of the `user.name` associated with Malware alert (local or remote actity, privileged or standard user).
- Verify if there are any other Alert types (Behavior or Memory Threat) associated with the same host or user or process within the same time.
### False positive analysis

- Other endpoint security vendors especially with their quarantine folders.
- Dynamically generated or compiled executables such as from csc.exe or other compilers. Due to the dynamic nature, each instance will likely have a unique hash and no signer

### Response and Remediation

- Initiate the incident response process based on the outcome of the triage.
  - If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps.
- Implement Elastic Endpoint Security to detect and prevent further post exploitation activities in the environment.
   - Contain the affected system by isolating it from the network to prevent further spread of the attack.
- If the triage identified malware, search the environment for additional compromised hosts.
  - Implement temporary network rules, procedures, and segmentation to contain the malware.
  - Stop suspicious processes.
  - Immediately block the identified indicators of compromise (IoCs).
  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
- Remove and block malicious artifacts identified during triage.
- Restore the affected system to its operational state by applying any necessary patches, updates, or configuration changes.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""
references = [
    "https://github.com/elastic/protections-artifacts/tree/main/yara",
    "https://docs.elastic.co/en/integrations/endpoint",
]
risk_score = 21
rule_id = "f87e6122-ea34-11ee-a417-f661ea17fbce"
rule_name_override = "message"
setup = """## Setup

### Elastic Defend Alerts
This rule is designed to capture specific alerts generated by Elastic Defend.

To capture all the Elastic Defend alerts, it is recommended to use all of the Elastic Defend feature-specific protection rules:

Behavior - Detected - Elastic Defend (UUID: 0f615fe4-eaa2-11ee-ae33-f661ea17fbce)
Behavior - Prevented - Elastic Defend (UUID: eb804972-ea34-11ee-a417-f661ea17fbce)
Malicious File - Detected - Elastic Defend (UUID: f2c3caa6-ea34-11ee-a417-f661ea17fbce)
Malicious File - Prevented - Elastic Defend (UUID: f87e6122-ea34-11ee-a417-f661ea17fbce)
Memory Threat - Detected - Elastic Defend (UUID: 017de1e4-ea35-11ee-a417-f661ea17fbce)
Memory Threat - Prevented - Elastic Defend (UUID: 06f3a26c-ea35-11ee-a417-f661ea17fbce)
Ransomware - Detected - Elastic Defend (UUID: 0c74cd7e-ea35-11ee-a417-f661ea17fbce)
Ransomware - Prevented - Elastic Defend (UUID: 10f3d520-ea35-11ee-a417-f661ea17fbce)

To avoid generating duplicate alerts, you should enable either all feature-specific protection rules or the Endpoint Security (Elastic Defend) rule (UUID: 9a1a2dae-0b5f-4c3d-8305-a268d404c306).

### 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 = "low"
tags = ["Data Source: Elastic Defend", "Tactic: Execution", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.kind : alert and event.code : malicious_file and event.type : denied and event.outcome : success
'''


[[rule.exceptions_list]]
id = "endpoint_list"
list_id = "endpoint_list"
namespace_type = "agnostic"
type = "endpoint"

[[rule.risk_score_mapping]]
field = "event.risk_score"
operator = "equals"
value = ""

[[rule.severity_mapping]]
field = "event.severity"
operator = "equals"
severity = "low"
value = "21"

[[rule.severity_mapping]]
field = "event.severity"
operator = "equals"
severity = "medium"
value = "47"

[[rule.severity_mapping]]
field = "event.severity"
operator = "equals"
severity = "high"
value = "73"

[[rule.severity_mapping]]
field = "event.severity"
operator = "equals"
severity = "critical"
value = "99"

[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1204"
name = "User Execution"
reference = "https://attack.mitre.org/techniques/T1204/"
[[rule.threat.technique.subtechnique]]
id = "T1204.002"
name = "Malicious File"
reference = "https://attack.mitre.org/techniques/T1204/002/"



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

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

[rule]
author = ["Elastic"]
description = """
Identifies the Internet Information Services (IIS) command-line tool, AppCmd, being used to dump sensitive configuration
data such as application pool credentials. An attacker with IIS web server access via a web shell can extract service
account passwords by requesting full configuration output or targeting credential-related fields.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
]
language = "eql"
license = "Elastic License v2"
name = "Microsoft IIS Service Account Password Dumped"
note = """ ## Triage and analysis

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

### Investigating Microsoft IIS Service Account Password Dumped

This rule detects the IIS administration utility being launched to print full web server configuration or credential-bearing settings, which can expose application pool usernames, passwords, and connection strings in clear text. An attacker who lands on a Windows web server through a web shell can run the tool to enumerate process model settings, recover the service account password, and reuse those credentials for lateral movement or deeper access to backend systems.

### Possible investigation steps

- Review the process tree, executing user, logon session, integrity level, and remote-interactive context to determine whether the command was launched by an authorized administrator, a scripted maintenance task, or through a suspicious parent such as cmd.exe, powershell.exe, w3wp.exe, or a web shell.
- Build a short timeline on the host around the execution to identify adjacent discovery or credential-access activity, including archive or encode tools, file staging in web directories, registry access, and outbound connections to unusual internal or external destinations.
- Inspect recent IIS and web server activity for signs of exploitation, such as requests to newly created ASPX or PHP files, requests containing command-execution parameters, uploads to writable web paths, or authentication bypass behavior preceding the event.
- Determine which application pools, virtual directories, or connection strings were exposed, then review subsequent authentication and service activity for the recovered account on other systems to spot lateral movement, privilege escalation, or access to databases and file shares.
- If the activity is unauthorized, preserve the relevant IIS configuration and web content for forensics, search the environment for the same account or host communicating elsewhere, and prioritize password rotation for affected service accounts and secrets.

### False positive analysis

- An IIS administrator may legitimately run AppCmd to review application pool identities or troubleshoot authentication issues, so verify the command aligns with an approved maintenance window or change request and was launched by an expected administrative account.
- A scheduled server administration script may enumerate full IIS configuration or connection strings during backup, migration validation, or configuration auditing, so confirm the parent process and execution time match a known scheduled task or recurring maintenance pattern and that no suspicious follow-on activity occurred.
"""
references = ["https://blog.netspi.com/decrypting-iis-passwords-to-break-out-of-the-dmz-part-1/"]
risk_score = 21
rule_id = "0564fb9d-90b9-4234-a411-82a546dc1343"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "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 : "appcmd.exe" or ?process.pe.original_file_name == "appcmd.exe") and
   process.args : "list" and
   (
     process.args : ("/text:*password*", "/text:*processModel*", "/text:*userName*", "/config", "*connectionstring*") or
     process.args == "/text:*"
   )
'''

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 = "T1003"
name = "OS Credential Dumping"
reference = "https://attack.mitre.org/techniques/T1003/"

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

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

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

[metadata]
creation_date = "2026/03/09"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/03/30"

[rule]
author = ["Elastic"]
description = """
Detects when the ScreenConnect client (ConnectWise Control) connects to a newly observed host server that is not the official ScreenConnect cloud. ScreenConnect is a common RMM/remote access tool abused for C2 and persistence. Self-hosted or non-standard relay servers may indicate abuse or compromise. The rule aggregates by server host (parsed from the client command line), requires first-time observation within the rule window, and limits to a single host to reduce noise.
"""
from = "now-5d"
interval = "6m"
language = "esql"
license = "Elastic License v2"
name = "Newly Observed ScreenConnect Host Server"
references = [
    "https://attack.mitre.org/techniques/T1219/002/",
    "https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-025a",
]
risk_score = 73
rule_id = "a8b2c4d6-e8f0-12a4-b6c8-d0e2f4a6b8c0"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Command and Control",
    "Resources: Investigation Guide",
    "Data Source: Elastic Defend"
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-endpoint.events.process-*
| where event.category == "process" and event.type == "start" and (process.name == "ScreenConnect.ClientService.exe" or process.code_signature.subject_name == "ConnectWise, LLC")
| grok process.command_line """e=Access&y=Guest&h=(?<Esql.screenconnect_server>[^&]+)&p"""
| where Esql.screenconnect_server is not null and not Esql.screenconnect_server like "*.screenconnect.com"
| stats Esql.count_distinct_host_id = count_distinct(host.id),
        Esql.first_time_seen = min(@timestamp),
        Esql.user_name_values = values(user.name),
        Esql.command_line_values = values(process.command_line),
        Esql.host_id_values = values(host.id),
        Esql.host_name_values = values(host.name),
        Esql.process_entity_id_values = values(process.entity_id) by Esql.screenconnect_server
| eval Esql.recent = date_diff("minute", Esql.first_time_seen, now())
| where Esql.recent <= 6 and Esql.count_distinct_host_id == 1
| eval host.id = mv_first(Esql.host_id_values),
       host.name = mv_first(Esql.host_name_values),
       process.command_line = mv_first(Esql.command_line_values),
       process.entity_id = mv_first(Esql.process_entity_id_values)
| keep host.id, host.name, process.command_line, process.entity_id, Esql.screenconnect_server, Esql.user_name_values, Esql.first_time_seen
'''

note = """## Triage and analysis

### Investigating Newly Observed ScreenConnect Host Server

#### Possible investigation steps

- What do the alert-preserved fields tell you about this new ScreenConnect relay?
  - Focus: `Esql.screenconnect_server`, `Esql.user_name_values`, `Esql.first_time_seen`, `host.id`, `host.name`, and `process.command_line`; note `Esql.*` fields are alert-local, not source-event records.
  - Implication: supports concern when the relay is an IP literal or unknown domain; weaker when it points to a recognized internal relay or managed service provider host.

- Does the ScreenConnect client binary and install path match recognized software on this host?
  - Focus: recover from source events via `process.entity_id`: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. $investigate_0
  - Implication: suspicious when unsigned, portable, user-writable, or mismatched to its original file name; consistent only when signer and path match the expected ScreenConnect installation.

- Does the parent and ancestry explain why this host initiated a new relay connection now?
  - Focus: from the recovered source event: `process.parent.executable`, `process.parent.command_line`, `process.Ext.ancestry`, and `process.Ext.session_info.logon_type`.
  - Implication: harder to justify when a script host, Office application, installer, or unexpected interactive session starts the client; easier to explain when the lineage resolves to a recognized service deployment or management tooling chain.

- Do network events show the host contacting infrastructure consistent with the parsed relay?
  - Why: `Esql.screenconnect_server` is an alert-level field, so source DNS and connection events are needed to confirm what the host actually contacted.
  - Focus: DNS "lookup_result" events for `Esql.screenconnect_server` and connection events scoped to `process.entity_id` and `host.id`, checking `dns.question.name`, `dns.resolved_ip`, `destination.ip`, and `destination.as.organization.name`. $investigate_1
  - Implication: supports concern when the process reaches public infrastructure with unknown ownership, or when multiple destinations cluster around the same relay; less concerning when the infrastructure matches the relay and belongs to a known hosting provider. Missing network telemetry is unresolved, not benign.

- Does the host context fit managed service provider or internal ScreenConnect use?
  - Focus: `host.id` and `Esql.user_name_values` pairing, and whether the same `Esql.screenconnect_server`, signer, and parent workflow recur across a known admin host group.
  - Implication: more concerning if ScreenConnect appears on end-user or sensitive hosts not typically managed remotely, or if the user and host evidence do not fit the expected workflow; more explainable when the same managed host group, operator identity, and deployment pattern recur together.

- Have other hosts in the environment resolved the same ScreenConnect relay domain?
  - Focus: DNS events across all hosts where `dns.question.name` matches the relay from `Esql.screenconnect_server` over the last 30 days. $investigate_2
  - Implication: multiple unrelated hosts resolving the same relay suggests a campaign or broad rollout; a single host stays locally bounded.

- Does this host show related alerts or adjacent remote-access tooling that suggest broader compromise?
  - Focus: related alerts for the same `host.id` in the last 48 hours, plus adjacent remote-access, persistence, credential-access, or delivery activity, especially renamed or portable ConnectWise or ScreenConnect binaries tied to the same relay. $investigate_3
  - Implication: suggests broader host compromise when the asset also shows suspicious precursor delivery, persistence, credential theft, or additional remote-access tooling; stays locally bounded when the surrounding alert history is limited to expected admin activity or unrelated benign activity.

- Escalate when the relay, client identity, launch lineage, contacted infrastructure, or host spread point to unauthorized remote access; close only when all evidence aligns with a recognized ScreenConnect workflow; if mixed or incomplete, preserve and escalate.

### False positive analysis

- Legitimate self-hosted ScreenConnect or managed service provider ConnectWise Control can trigger this rule. Confirm when the same `Esql.screenconnect_server`, recovered `process.executable`, signer, parent workflow, and DNS evidence all align with one recognized operator. If change records are unavailable, require the same client identity and admin host group to show prior new-relay alerts from this rule.
- Before creating an exception, confirm the relay is authorized through organizational records, then build the exception on the relay domain in `process.command_line`. Avoid exceptions on `host.name` or `host.id` alone, since the rule fires per host and those would suppress only one endpoint.

### Response and remediation

- If confirmed benign, reverse any temporary containment and document the authorized relay, client signer and path, and source-event lineage. Build the exception on the relay domain in `process.command_line` once authorization is confirmed through organizational records.
- If suspicious but unconfirmed, preserve the alert's `process.entity_id`, `process.command_line`, `Esql.screenconnect_server`, and any linked `dns.question.name` or `destination.ip` evidence. Apply reversible containment such as temporary DNS or egress blocking for the relay host. Escalate to host isolation only when the relay, lineage, or network evidence shows meaningful risk and the host's support role can tolerate it. Avoid destructive cleanup until scope is clearer.
- If confirmed malicious, document the alert's `process.entity_id`, recovered `process.executable`, `process.code_signature.subject_name`, `process.command_line`, `Esql.screenconnect_server`, and any confirmed `dns.question.name` or `destination.ip` values before initiating response actions. Use available endpoint response integrations to isolate the host when the relay, client identity, lineage, or contacted infrastructure indicates unauthorized remote access. If direct endpoint response is unavailable, escalate with the documented artifacts to the team that can act.
- Review how the software was installed, who operated the relay, and whether additional remote-access tooling or credential exposure is present on the host. Then block the malicious relay host and any confirmed relay IPs, and remove or disable the unauthorized ScreenConnect client, service, persistence mechanism, or installer artifacts identified during the investigation.
- After containment, enforce approved-relay policy for remote-access tools and retain Elastic Defend process and network telemetry needed to validate future relay changes.
"""

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

[rule.investigation_fields]
field_names = [
    "host.id",
    "host.name",
    "process.command_line",
    "Esql.screenconnect_server",
    "Esql.user_name_values",
    "Esql.first_time_seen",
    "process.entity_id",
]

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

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

[[transform.investigate]]
label = "Hosts resolving the same ScreenConnect relay domain"
description = ""
providers = [
  [
    { excluded = false, field = "dns.question.name", queryType = "phrase", value = "{{Esql.screenconnect_server}}", valueType = "string" }
  ]
]
relativeFrom = "now-30d/d"
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 = "T1219"
name = "Remote Access Tools"
reference = "https://attack.mitre.org/techniques/T1219/"
[[rule.threat.technique.subtechnique]]
id = "T1219.002"
name = "Remote Desktop Software"
reference = "https://attack.mitre.org/techniques/T1219/002/"

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