Elastic rules: 1f

[rule]
description = """
Identifies attempts to modify the permissions or write to Microsoft Anti Malware Scan Interface DLL from unsigned
module.
"""
id = "64043824-bd8f-408d-a92b-3e552b6ecd20"
license = "Elastic License v2"
name = "AMSI Bypass from Suspicious Module"
os_list = ["windows"]
reference = [
    "https://aidenpearce369.github.io/offsec/AMSI-Memory-Bypass/",
    "https://modexp.wordpress.com/2019/06/03/disable-amsi-wldp-dotnet/",
]
version = "1.0.8"

query = '''
api where process.Ext.api.metadata.target_address_name like "amsi.dll*" and
 ((process.Ext.api.name in ("VirtualProtect", "VirtualProtectEx") and process.Ext.api.parameters.protection like "?W*") or
  process.Ext.api.name == "WriteProcessMemory") and
  not process.thread.Ext.call_stack_final_user_module.protection_provenance like "Kernel*" and
  not process.thread.Ext.call_stack_final_user_module.name in ("Kernel", "Unknown", "Undetermined") and
  not process.thread.Ext.call_stack_final_user_module.hash.sha256 in
                                  ("2ef4add3ecdc20e1234b0c3fa034cf110f5dfc01355f81ed773f797fcdc6a375",
                                   "c2710daef53ff962522ec1e7e05cdc7147db3371dfbc71cb1cf7afe6382451e5",
                                   "15dd664aee6bfd3cbe0a967d160f4f4b37fe3e8aef88dfb4547e77292226c0c4",
                                   "a121de30d1b8cdf66d886f8cd02b4a35d477f2638d616673da76716a9466cae7",
                                   "ce0644768cd505a8975d897a560186011fbcd2cbd6b309eb0688fc4d816a3451",
                                   "23217cdb3ff108ee4e099f61afa6e33f65675ae0c25d7cc0a30554deca1b33dc",
                                   "d0c7983d45bbbe52e10aa461226cef4049d30778a5d03c9663251edbcea5bd6e",
                                   "b6f6b9f49c60a2230cbf1a3449c85434b70a3b46cc3727da3ef265ba46ac4967",
                                   "902080ae0b0348dca5d526b8cefee280fec0e4eb7299af211ad522e6644032f4",
                                   "5eea4cecd56c5c12f748a2c06729448419ca4deec2410314b6e9d184ecf64bad",
                                   "384c31b964bac7f60c637ed032d735537adebf3611f78637887d042330655f24",
                                   "4776e752dab37e0540f4f3b66a6686e549a9eba42ddfe2f22ee8bcd8e11d215e",
                                   "3505e9318d1ca3472c7708ebaa1753b5cc0eda43c6f5210807a9e7ca8673a227",
                                   "1ee57272a271e82eee1aebaab306c403b30a2e9df94ede777f17fe84670e5033") and
  (
   _arraysearch(process.thread.Ext.call_stack_final_user_module.code_signature, $entry, $entry.trusted == false or $entry.exists == false) or
   _arraysearch(process.thread.Ext.call_stack_final_user_module.code_signature, $entry, $entry.subject_name in ("Microsoft Corporation", "Microsoft Windows", ".NET", "Python Software Foundation"))
  ) and
  not _arraysearch(process.thread.Ext.call_stack_final_user_module.code_signature, $entry, $entry.trusted == true and
                  $entry.subject_name in ("Microsoft Windows Hardware Compatibility Publisher",
                                          "Microsoft Windows Software Compatibility Publisher",
                                          "MUSARUBRA US LLC")) and
  not process.thread.Ext.call_stack_final_user_module.path like
                                     ("c:\\windows\\system32\\apphelp.dll",
                                      "c:\\windows\\system32\\lsasrv.dll",
                                      "c:\\windows\\system32\\combase.dll",
                                      "c:\\windows\\system32\\ieadvpack.dll",
                                      "c:\\windows\\syswow64\\*.dll",
                                      "c:\\windows\\microsoft.net\\framework*.dll",
                                      "c:\\windows\\assembly\\nativeimages_*.ni.dll",
                                      "c:\\windows\\winsxs\\temp\\pendingdeletes\\$$deleteme*",
                                      "c:\\windows\\system32\\mrt\\*\\mpengine.dll",
                                      "c:\\windows\\system32\\wbem\\fastprox.dll",
                                      "c:\\windows\\winsxs\\*.dll",
                                      "c:\\program files (x86)\\*",
                                      "c:\\program files\\*",
                                      "c:\\windows\\syswow64\\werfault.exe") and
  not process.thread.Ext.call_stack_final_user_module.protection_provenance_path like
                                                     ("c:\\windows\\microsoft.net\\framework*\\clr.dll",
                                                      "c:\\windows\\syswow64\\combase.dll",
                                                      "c:\\windows\\system32\\combase.dll") and
  not (process.executable : "C:\\Windows\\ccmsetup\\cache\\ccmsetup.exe" and
       process.parent.executable : ("C:\\Windows\\CCM\\CcmEval.exe", "C:\\Program Files\\SMS_CCM\\CcmEval.exe", "C:\\Windows\\CCM\\ccmrepair.exe")) and
  not (process.Ext.api.name == "VirtualProtect" and
       _arraysearch(process.thread.Ext.call_stack, $entry, $entry.symbol_info like ("c:\\windows\\sys?????\\ntdll.dll!LdrLoadDll*", "c:\\windows\\sys?????\\kernelbase.dll!LoadLibrary*")))
'''

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Authorization plugins are used to extend the authorization services API and implement mechanisms that are not natively
supported by the OS, such as multi-factor authentication with third party software. Adversaries may abuse this feature
to persist and/or collect clear text credentials as they traverse the registered plugins during user logon.
"""
from = "now-9m"
index = ["logs-endpoint.events.*"]
language = "eql"
license = "Elastic License v2"
name = "Authorization Plugin Modification"
references = [
    "https://developer.apple.com/documentation/security/authorization_plug-ins",
    "https://www.xorrior.com/persistent-credential-theft/",
]
risk_score = 47
rule_id = "e6c98d38-633d-4b3e-9387-42112cd5ac10"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

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

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

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

query = '''
file where host.os.type == "macos" and event.action == "modification" and
  file.path like "/Library/Security/SecurityAgentPlugins/*" and
  not file.path like ("/Library/Security/SecurityAgentPlugins/KandjiPassport.bundle/*", "/Library/Security/SecurityAgentPlugins/TeamViewerAuthPlugin.bundle/*") and
  not process.name == "shove"
'''
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 Authorization Plugin Modification

Authorization plugins in macOS extend authentication capabilities, enabling features like third-party multi-factor authentication. Adversaries may exploit these plugins to maintain persistence or capture credentials by modifying or adding unauthorized plugins. The detection rule identifies suspicious modifications by monitoring changes in specific plugin directories, excluding known legitimate plugins and trusted processes, thus highlighting potential unauthorized activities.

### Possible investigation steps

- Review the file path of the modified plugin to determine if it is located in the /Library/Security/SecurityAgentPlugins/ directory and verify if it is not among the known legitimate plugins like KandjiPassport.bundle or TeamViewerAuthPlugin.bundle.
- Examine the process name associated with the modification event to ensure it is not 'shove' with a trusted code signature, as these are excluded from the detection rule.
- Investigate the history of the modified plugin file to identify when it was created or last modified and by which user or process, to assess if the change aligns with expected administrative activities.
- Check for any recent user logon events that might correlate with the timing of the plugin modification to identify potential unauthorized access attempts.
- Analyze any associated network activity or connections from the host around the time of the modification to detect possible data exfiltration or communication with external command and control servers.
- Review system logs for any other suspicious activities or anomalies that occurred around the same time as the plugin modification to gather additional context on the potential threat.

### False positive analysis

- Known legitimate plugins such as KandjiPassport.bundle and TeamViewerAuthPlugin.bundle may trigger alerts if they are updated or modified. Users can handle these by ensuring these plugins are included in the exclusion list within the detection rule.
- Trusted processes like those signed by a verified code signature, such as the process named 'shove', might be flagged if they interact with the plugin directories. Users should verify the code signature and add these processes to the trusted list to prevent false positives.
- System updates or legitimate software installations may cause temporary changes in the plugin directories. Users should monitor for these events and temporarily adjust the detection rule to exclude these known activities during the update period.
- Custom or in-house developed plugins that are not widely recognized may be flagged. Users should ensure these plugins are properly documented and added to the exclusion list if they are verified as safe and necessary for business operations.

### Response and remediation

- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or further unauthorized access.
- Review and terminate any suspicious processes associated with unauthorized plugins, especially those not signed by a trusted code signature.
- Remove any unauthorized or suspicious plugins from the /Library/Security/SecurityAgentPlugins/ directory to eliminate persistence mechanisms.
- Conduct a thorough credential audit for any accounts that may have been compromised, and enforce a password reset for affected users.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
- Implement additional monitoring on the affected system and similar endpoints to detect any further unauthorized plugin modifications.
- Review and update security policies to ensure only authorized personnel can modify or add authorization plugins, and consider implementing stricter access controls."""


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

[[rule.threat.technique]]
id = "T1547"
name = "Boot or Logon Autostart Execution"
reference = "https://attack.mitre.org/techniques/T1547/"

[[rule.threat.technique.subtechnique]]
id = "T1547.002"
name = "Authentication Package"
reference = "https://attack.mitre.org/techniques/T1547/002/"

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

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Identifies the deletion of an Amazon Elastic Compute Cloud (EC2) network access control list (ACL) or one of its ingress/egress entries.
"""
false_positives = [
    """
    Network ACL's may be deleted by a network administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Network ACL 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-*"]
interval = "5m"
language = "kuery"
license = "Elastic License v2"
name = "AWS EC2 Network Access Control List Deletion"
note = """## Triage and analysis

### Investigating AWS EC2 Network Access Control List Deletion

AWS EC2 Network ACLs are essential for controlling inbound and outbound traffic to subnets, acting as a firewall layer. Adversaries may delete these ACLs to disable security controls, facilitating unauthorized access or data exfiltration. The detection rule monitors AWS CloudTrail logs for successful deletion events of ACLs or their entries, signaling potential defense evasion attempts.

### Possible investigation steps

- Review the AWS CloudTrail logs to identify the specific user or role associated with the deletion event by examining the user identity information in the logs.
- Check the time and date of the deletion event to determine if it coincides with any other suspicious activities or known maintenance windows.
- Investigate the source IP address and location from which the deletion request was made to assess if it aligns with expected access patterns or if it appears anomalous.
- Examine the AWS account activity around the time of the event to identify any other unusual actions or changes, such as the creation of new resources or modifications to existing ones.
- Assess the impact of the deleted Network ACL or entries by identifying the affected subnets and evaluating the potential exposure or risk to the network.
- Review any recent changes to IAM policies or roles that might have inadvertently granted excessive permissions to users or services, allowing them to delete Network ACLs.

### False positive analysis

- Routine maintenance or updates by authorized personnel may trigger deletion events. Verify if the deletion aligns with scheduled maintenance activities and consider excluding these events from alerts.
- Automated scripts or infrastructure-as-code tools like Terraform or CloudFormation might delete and recreate ACLs as part of normal operations. Identify these tools and exclude their actions from triggering alerts.
- Changes in network architecture or security policy updates can lead to legitimate ACL deletions. Document these changes and adjust the detection rule to ignore such planned modifications.
- Ensure that the AWS accounts involved in the deletion events are recognized and trusted. Exclude actions from these accounts if they are part of regular administrative tasks.
- Collaborate with the security team to establish a baseline of normal ACL deletion activities and refine the detection rule to minimize false positives based on this baseline.

### Response and remediation

- Immediately isolate the affected subnet to prevent further unauthorized access or data exfiltration. This can be done by applying a restrictive security group or temporarily removing the subnet from the VPC.
- Review AWS CloudTrail logs to identify the source of the deletion event, including the IAM user or role responsible, and assess whether the action was authorized or part of a larger compromise.
- Recreate the deleted Network ACL or its entries using the most recent backup or configuration documentation to restore intended security controls.
- Implement a temporary monitoring solution to track any further unauthorized changes to network ACLs or related security configurations.
- Escalate the incident to the security operations team for a comprehensive investigation to determine the root cause and scope of the breach, including potential lateral movement or data exfiltration.
- Revoke or rotate credentials for any compromised IAM users or roles involved in the deletion event to prevent further unauthorized actions.
- Enhance detection capabilities by configuring alerts for any future unauthorized changes to network ACLs, ensuring rapid response to similar threats.

## Setup

The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/delete-network-acl.html",
    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteNetworkAcl.html",
    "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/delete-network-acl-entry.html",
    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteNetworkAclEntry.html",
]
risk_score = 47
rule_id = "8623535c-1e17-44e1-aa97-7a0699c3037d"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS EC2",
    "Tactic: Defense Evasion",
    "Rule Type: Custom Query (KQL)",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:(DeleteNetworkAcl or DeleteNetworkAclEntry) and event.outcome:success
    and not user_agent.original: (*Terraform* or *Pulumi* or *Ansible*)
'''
[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user_agent.original",
    "source.address",
    "aws.cloudtrail.user_identity.arn",
    "aws.cloudtrail.user_identity.type",
    "aws.cloudtrail.user_identity.access_key_id",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
    "aws.cloudtrail.response_elements"
]

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


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

[metadata]
creation_date = "2026/02/10"
integration = ["aws"]
maturity = "production"
updated_date = "2026/07/08"

[rule]
author = ["Elastic"]
description = """
Identifies sensitive AWS IAM operations performed via AWS CloudShell based on the user agent string. CloudShell is a
browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. While
convenient for administrators, CloudShell access from compromised console sessions can enable attackers to perform
privileged operations without installing tools or using programmatic credentials. This rule detects high-risk actions
such as creating IAM users, access keys, roles, or attaching policies when initiated from CloudShell, which may indicate
post-compromise credential harvesting or privilege escalation activity.
"""
false_positives = [
    """
    Administrators may legitimately use CloudShell for IAM management tasks during routine operations or
    troubleshooting. Verify whether the user, source IP, and specific actions align with expected administrative
    workflows. Establish a baseline of normal CloudShell usage patterns to reduce false positives.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Sensitive IAM Operations Performed via CloudShell"
note = """## Triage and analysis

### Investigating AWS Sensitive IAM Operations Performed via CloudShell

AWS CloudShell is a browser-based shell environment that provides instant command-line access to AWS resources without requiring local CLI installation or credential configuration. While this is convenient for legitimate administrators, it also provides adversaries with a powerful tool if they gain access to a compromised AWS console session. Attackers can use CloudShell to perform sensitive operations without leaving artifacts on their local systems.

This rule detects high-risk IAM operations performed via CloudShell, including credential creation, user management, and policy attachment. These actions are commonly seen in post-compromise scenarios where attackers establish persistence or escalate privileges.

### Possible investigation steps

- **Identify the actor**
  - Review `aws.cloudtrail.user_identity.arn` to determine which IAM principal performed the action.
  - Check `source.ip` and `source.geo` fields to verify the request origin matches expected administrator locations.
  - Investigate the console login event that established the CloudShell session.

- **Analyze the specific action**
  - Review `event.action` to understand exactly what operation was performed.
  - For `CreateAccessKey` or `CreateUser`, identify the target principal and assess whether this was authorized.
  - For policy attachments, review which policies were attached and to which entities.

- **Review request and response details**
  - Examine `aws.cloudtrail.request_parameters` for specifics like user names, policy ARNs, or role configurations.
  - Check `aws.cloudtrail.response_elements` for created resource identifiers.

- **Correlate with surrounding activity**
  - Search for preceding events such as `ConsoleLogin` from the same session or IP address.
  - Look for MFA bypass indicators or unusual login patterns before CloudShell usage.
  - Check for subsequent use of any created credentials or roles.

- **Assess the broader context**
  - Determine if this CloudShell usage pattern is typical for this user.
  - Review recent access patterns for the console session that initiated CloudShell.

### False positive analysis

- Routine administrative tasks using CloudShell are common in some organizations. Create baseline profiles for users who regularly use CloudShell.
- Infrastructure automation testing may involve CloudShell for quick validation. Verify with the user.


### Response and remediation

- If unauthorized, immediately terminate the console session and revoke any created credentials.
- Rotate credentials for any IAM users or roles that may have been compromised.
- Review and remove any unauthorized users, access keys, roles, or policy attachments.
- Consider restricting CloudShell access via SCPs or IAM policies for sensitive accounts.
- Implement session duration limits to reduce the window of opportunity for console session abuse.

### 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)** 
"""
references = [
    "https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html",
    "https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud",
    "https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a",
]
risk_score = 73
rule_id = "41554afd-d839-4cc2-b185-170ac01cbefc"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS CloudTrail",
    "Data Source: AWS IAM",
    "Tactic: Persistence",
    "Tactic: Privilege Escalation",
    "Use Case: Threat Detection",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "iam.amazonaws.com"
    and event.action: (
        "CreateAccessKey" or
        "CreateUser" or
        "AttachUserPolicy" or
        "PutUserPolicy" or
        "CreateRole" or
        "AttachRolePolicy" or
        "PutRolePolicy" or
        "CreateInstanceProfile" or
        "AddRoleToInstanceProfile"
    )
    and event.outcome: "success"
    and user_agent.original: *CloudShell*
'''


[[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.technique]]
id = "T1136"
name = "Create Account"
reference = "https://attack.mitre.org/techniques/T1136/"

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

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

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

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

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

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

[rule.threat.tactic]
id = "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",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
    "aws.cloudtrail.response_elements",
]

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

[rule]
author = ["Elastic"]
description = """
Base16 and Base32 are encoding schemes that convert binary data into text, making it easier to transmit and store. This rule
monitors for Base16 or Base32 encoding and decoding activity on Linux systems. Attackers may use these encoding schemes to
obfuscate malicious payloads, evade detection, and facilitate data exfiltration. 
"""
false_positives = [
    """
    Automated tools such as Jenkins may encode or decode files as part of their normal behavior. These events can be
    filtered by the process executable or username values.
    """,
]
from = "now-9m"
index = [
    "auditbeat-*",
    "endgame-*",
    "logs-auditd_manager.auditd-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Base16 or Base32 Encoding/Decoding Activity"
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 Base16 or Base32 Encoding/Decoding Activity

Base16 and Base32 are encoding schemes used to convert binary data into text, facilitating data transmission and storage. Adversaries exploit these encodings to obfuscate malicious payloads, evading detection by security systems. The detection rule identifies suspicious encoding/decoding activities on Linux systems by monitoring specific processes and actions, excluding benign uses like help or version checks.

### Possible investigation steps

- Review the process name and arguments to confirm if the activity is related to encoding/decoding using base16 or base32, ensuring it is not a benign use case like help or version checks.
- Examine the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious.
- Check the parent process of the encoding/decoding activity to identify if it was initiated by a legitimate application or a potentially malicious script or program.
- Investigate the timing and frequency of the encoding/decoding events to assess if they coincide with other suspicious activities or known attack patterns.
- Correlate the event with network activity logs to see if there is any data exfiltration attempt or communication with known malicious IP addresses or domains.
- Look into any recent changes or anomalies in the system that might indicate a compromise, such as unauthorized file modifications or new user accounts.

### False positive analysis

- Routine administrative tasks may trigger the rule if administrators use base16 or base32 commands for legitimate data encoding or decoding. To manage this, create exceptions for specific user accounts or scripts known to perform these tasks regularly.
- Automated backup or data transfer processes might use base16 or base32 encoding as part of their operations. Identify these processes and exclude them by specifying their unique process arguments or execution paths.
- Development and testing environments often involve encoding and decoding operations for debugging or data manipulation. Exclude these environments by filtering based on hostnames or IP addresses associated with non-production systems.
- Security tools or scripts that perform regular encoding checks for data integrity or compliance purposes can also trigger false positives. Whitelist these tools by their process names or execution contexts to prevent unnecessary alerts.
- Educational or research activities involving encoding techniques may inadvertently match the rule criteria. Consider excluding known educational user groups or specific research project identifiers to reduce false positives.

### Response and remediation

- Isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary.
- Terminate any suspicious processes identified by the detection rule, specifically those involving base16 or base32 encoding/decoding without benign arguments.
- Conduct a thorough review of recent system logs and process execution history to identify any additional suspicious activities or related processes.
- Remove any malicious files or payloads that have been identified as part of the encoding/decoding activity.
- Restore any affected files or systems from known good backups to ensure system integrity and data accuracy.
- Update and patch the affected system to close any vulnerabilities that may have been exploited by the adversary.
- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
risk_score = 47
rule_id = "debff20a-46bc-4a4d-bae5-5cdd14222795"
setup = """## Setup

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

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

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

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

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

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

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

[[rule.threat.technique]]
id = "T1027"
name = "Obfuscated Files or Information"
reference = "https://attack.mitre.org/techniques/T1027/"

[[rule.threat.technique]]
id = "T1140"
name = "Deobfuscate/Decode Files or Information"
reference = "https://attack.mitre.org/techniques/T1140/"

[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 = "T1132"
name = "Data Encoding"
reference = "https://attack.mitre.org/techniques/T1132/"

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

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

[metadata]
creation_date = "2021/07/15"
integration = ["o365"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic", "Austin Songer"]
description = """
Identifies when Microsoft Cloud App Security flags potential ransomware activity in Microsoft 365. This rule detects
events where the Security Compliance Center reports a "Ransomware activity" or "Potential ransomware activity" alert,
which may indicate file encryption, mass file modifications, or uploads of ransomware-infected files to cloud services
such as SharePoint or OneDrive.
"""
false_positives = [
    """
    If Cloud App Security identifies, for example, a high rate of file uploads or file deletion activities it may
    represent an adverse encryption process.
    """,
]
from = "now-9m"
index = ["logs-o365.audit-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "Deprecated - M365 Security Compliance Potential Ransomware Activity"
note = """## Triage and analysis

### Investigating Deprecated - M365 Security Compliance Potential Ransomware Activity

Microsoft 365's cloud services can be exploited by adversaries to distribute ransomware by uploading infected files. This detection rule leverages Microsoft Cloud App Security to identify suspicious uploads, focusing on successful events flagged as potential ransomware activity. By monitoring specific event datasets and actions, it helps security analysts pinpoint and mitigate ransomware threats, aligning with MITRE ATT&CK's impact tactics.

### Possible investigation steps

- Identify the affected user account and review their recent file activity in Microsoft 365 for signs of mass file encryption, renaming with unusual extensions, or rapid file modifications.
- Examine the file names, extensions, and metadata of the flagged uploads to determine if they match known ransomware patterns (e.g., `.encrypted`, `.locked`, or ransom note files like `README.txt` or `DECRYPT_INSTRUCTIONS.html`).
- Correlate this alert with other security events from the same user or source IP, such as impossible travel, failed login attempts, or suspicious inbox rules, to identify potential account compromise.
- Check whether the affected user's endpoint shows signs of ransomware execution, such as high CPU usage, mass file system changes, or known ransomware process names.
- Review SharePoint or OneDrive file version history to determine the scope of encrypted or modified files and whether recovery via version rollback is possible.
- Contact the user to verify whether the activity is legitimate or if their account or device may have been compromised.

### False positive analysis

- Legitimate file uploads by trusted users may trigger alerts if the files are mistakenly flagged as ransomware. To manage this, create exceptions for specific users or groups who frequently upload large volumes of files.
- Automated backup processes that upload encrypted files to the cloud can be misidentified as ransomware activity. Exclude these processes by identifying and whitelisting the associated service accounts or IP addresses.
- Certain file types or extensions commonly used in business operations might be flagged. Review and adjust the detection rule to exclude these file types if they are consistently identified as false positives.
- Collaborative tools that sync files across devices may cause multiple uploads that appear suspicious. Monitor and exclude these tools by recognizing their typical behavior patterns and adjusting the rule settings accordingly.

### Response and remediation

- Immediately isolate the affected user account to prevent further uploads and potential spread of ransomware within the cloud environment.
- Quarantine the uploaded files flagged as potential ransomware to prevent access and further distribution.
- Conduct a thorough scan of the affected user's devices and cloud storage for additional signs of ransomware or other malicious activity.
- Notify the security operations team to initiate a deeper investigation into the source and scope of the ransomware activity.
- Restore any affected files from secure backups, ensuring that the backups are clean and free from ransomware.
- Review and update access controls and permissions for the affected user and related accounts to minimize the risk of future incidents.
- Escalate the incident to senior security management and, if necessary, involve legal or compliance teams to assess any regulatory implications.
"""
references = [
    "https://docs.microsoft.com/en-us/cloud-app-security/anomaly-detection-policy",
    "https://docs.microsoft.com/en-us/cloud-app-security/policy-template-reference",
    "https://www.microsoft.com/en-us/security/blog/threat-intelligence/ransomware/",
]
risk_score = 47
rule_id = "721999d0-7ab2-44bf-b328-6e63367b9b29"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: SaaS",
    "Data Source: Microsoft 365",
    "Data Source: Microsoft 365 Audit Logs",
    "Use Case: Threat Detection",
    "Tactic: Impact",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:o365.audit and
    event.provider:SecurityComplianceCenter and
    event.category:web and
    rule.name:("Ransomware activity" or "Potential ransomware activity") and
    event.outcome:success
'''


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

[[rule.threat.technique]]
id = "T1486"
name = "Data Encrypted for Impact"
reference = "https://attack.mitre.org/techniques/T1486/"

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Identifies changes to the DNS Global Query Block List (GQBL), a security feature that prevents the resolution of certain
DNS names often exploited in attacks like WPAD spoofing. Attackers with certain privileges, such as DNSAdmins, can
modify or disable the GQBL, allowing exploitation of hosts running WPAD with default settings for privilege escalation
and lateral movement.
"""
from = "now-9m"
index = [
    "logs-endpoint.events.registry-*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "endgame-*",
    "logs-crowdstrike.fdr*",
]
language = "eql"
license = "Elastic License v2"
name = "DNS Global Query Block List Modified or Disabled"
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 DNS Global Query Block List Modified or Disabled

The DNS Global Query Block List (GQBL) is a security feature in Windows environments that blocks the resolution of specific DNS names, such as WPAD, to prevent attacks like spoofing. Adversaries with elevated privileges can alter or disable the GQBL, enabling them to exploit default settings for privilege escalation. The detection rule monitors registry changes indicating such modifications, flagging potential defense evasion attempts.

### Possible investigation steps

- Review the registry event logs to confirm the specific changes made to the DNS Global Query Block List, focusing on the registry values "EnableGlobalQueryBlockList" and "GlobalQueryBlockList".
- Identify the user account associated with the registry change event to determine if the account has elevated privileges, such as DNSAdmins, which could indicate potential misuse.
- Check for any recent changes in user permissions or group memberships that might have granted the necessary privileges to modify the GQBL.
- Investigate any other suspicious activities or alerts related to the same user or host around the time of the registry change to identify potential lateral movement or privilege escalation attempts.
- Correlate the event with network traffic logs to detect any unusual DNS queries or attempts to resolve WPAD or other blocked names, which could suggest exploitation attempts.
- Review system and security logs for any signs of unauthorized access or other indicators of compromise on the affected host.

### False positive analysis

- Legitimate administrative changes to DNS settings by IT staff can trigger the rule. To manage this, create exceptions for known maintenance windows or authorized personnel making these changes.
- Automated scripts or software updates that modify DNS settings might be flagged. Identify and whitelist these processes if they are verified as safe and necessary for system operations.
- Changes made by security tools or network management software that adjust DNS settings for legitimate reasons can be mistaken for threats. Review and exclude these tools from monitoring if they are part of the organization's approved security infrastructure.
- In environments where WPAD is intentionally used, the absence of "wpad" in the GlobalQueryBlockList might be a normal configuration. Document and exclude these cases if they align with the organization's network design and security policies.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement.
- Revert any unauthorized changes to the DNS Global Query Block List by restoring the registry settings to their default state, ensuring WPAD and other critical entries are included.
- Conduct a thorough review of user accounts with elevated privileges, such as DNSAdmins, to identify any unauthorized access or privilege escalation. Revoke unnecessary privileges and reset credentials as needed.
- Deploy endpoint detection and response (EDR) tools to scan the affected system for additional indicators of compromise or malicious activity, focusing on defense evasion techniques.
- Monitor network traffic for signs of WPAD spoofing or other related attacks, and implement network segmentation to limit the impact of potential threats.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
- Update security policies and procedures to include specific measures for monitoring and protecting the DNS Global Query Block List, ensuring rapid detection and response to similar threats in the future."""
references = [
    "https://cube0x0.github.io/Pocing-Beyond-DA/",
    "https://www.thehacker.recipes/ad/movement/mitm-and-coerced-authentications/wpad-spoofing",
    "https://www.netspi.com/blog/technical-blog/network-penetration-testing/adidns-revisited/",
]
risk_score = 47
rule_id = "57bfa0a9-37c0-44d6-b724-54bf16787492"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: Microsoft Defender XDR",
    "Data Source: SentinelOne",
    "Data Source: Elastic Endgame",
    "Data Source: Crowdstrike",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
registry where host.os.type == "windows" and event.type == "change" and registry.data.strings != null and
(
  (registry.value : "EnableGlobalQueryBlockList" and registry.data.strings : ("0", "0x00000000")) or
  (registry.value : "GlobalQueryBlockList" and not registry.data.strings : "wpad")
)
'''

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 Registry Events](https://ela.st/sysmon-event-reg-setup)
"""


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

[[rule.threat.technique]]
id = "T1112"
name = "Modify Registry"
reference = "https://attack.mitre.org/techniques/T1112/"

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

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

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

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

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

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

[rule]
description = "Detects attempts to download and execute a file via a Windows Installer CustomAction."
id = "70c01e6b-bc59-411e-9bf7-6a46e08d953b"
license = "Elastic License v2"
name = "Execution via MsiExec DownloadAndExecute CustomAction"
os_list = ["windows"]
version = "1.0.3"

query = '''
sequence with maxspan=1m
 [process where event.action == "start" and process.name : "rundll32.exe" and
  process.command_line : "*!CustomActions.DownloadAndExecute*"] by process.entity_id
 [dns where event.action == "lookup_requested" and
  process.name : "rundll32.exe" and dns.question.name : "?*"] by process.entity_id
 [process where event.action == "start" and process.parent.name : "rundll32.exe"] by process.parent.entity_id
'''

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

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

[[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.007"
name = "Msiexec"
reference = "https://attack.mitre.org/techniques/T1218/007/"

[[threat.technique.subtechnique]]
id = "T1218.011"
name = "Rundll32"
reference = "https://attack.mitre.org/techniques/T1218/011/"



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

[internal]
min_endpoint_version = "8.10.0"

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

[rule]
author = ["Elastic"]
description = """
Detects a sequence where a principal creates or modifies a Role/ClusterRole to include high-risk permissions
(e.g., wildcard access or escalation verbs) and then creates or patches a workload resource (DaemonSet,
Deployment, or CronJob) shortly after, which may indicate RBAC-based privilege escalation followed by payload
deployment. This pattern is often used by adversaries to gain unauthorized access to sensitive resources and
deploy malicious payloads.
"""
index = ["logs-kubernetes.audit_logs-*"]
language = "eql"
license = "Elastic License v2"
name = "Kubernetes Sensitive RBAC Change Followed by Workload Modification"
note = """ ## Triage and analysis

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

### Investigating Kubernetes Sensitive RBAC Change Followed by Workload Modification

This rule detects when a user grants or broadens high-risk permissions in a Role/ClusterRole and then quickly creates or patches a DaemonSet, Deployment, or CronJob, a strong signal of RBAC-driven privilege escalation followed by payload deployment. Attackers often add wildcard access or escalation verbs to a new role, bind it to their identity, then patch a workload to run a malicious container across nodes or on a schedule to establish persistence.

### Possible investigation steps

- Review the Role/ClusterRole change diff to identify newly granted wildcard resources/verbs or escalation permissions (e.g., bind, impersonate, escalate) and determine the effective access increase for the actor.
- Identify any RoleBinding/ClusterRoleBinding creations or updates around the same time to see whether the modified role was bound to the same principal or a newly created service account.
- Inspect the subsequent DaemonSet/Deployment/CronJob spec changes for malicious indicators such as new images, added initContainers, elevated securityContext (privileged/hostPID/hostNetwork), hostPath mounts, or suspicious command/args.
- Correlate pod runtime activity from the modified workload (image pulls, container starts, outbound connections, and access to secrets/configmaps) to confirm execution and scope of impact.
- Validate the actor’s legitimacy by checking whether the request originated from expected IP/user-agent and whether the identity is associated with approved CI/CD automation or an unusual interactive session.

### False positive analysis

- A platform engineer performing an urgent, legitimate RBAC adjustment (e.g., expanding a Role/ClusterRole for a new feature rollout) and then immediately patching or deploying a DaemonSet/Deployment/CronJob as part of the same change window can match this sequence.
- A CI/CD pipeline or GitOps-style workflow using a non-system:masters identity may update RBAC manifests and then apply workload updates within minutes during routine releases, producing this pattern without malicious intent.

### Response and remediation

- Immediately revoke or roll back the risky Role/ClusterRole changes and remove any new/updated RoleBinding/ClusterRoleBinding that ties the elevated permissions to the triggering user or service account.
- Quarantine the modified Deployment/DaemonSet/CronJob by scaling it to zero or deleting it and cordon/drain affected nodes if pods ran privileged, used hostPath mounts, or executed on many nodes.
- Rotate credentials and access paths exposed through the workload (service account tokens, kubeconfig files, mounted secrets, cloud keys) and invalidate any newly issued tokens tied to the actor.
- For eradication and recovery, redeploy workloads from trusted Git/registry sources, block the suspicious images/digests in admission controls, and verify no persistence remains via CronJobs, DaemonSets, webhook configurations, or additional RBAC bindings.
- Escalate to incident response and platform leadership if the RBAC change included wildcard permissions or escalation verbs, if the workload ran privileged/hostNetwork/hostPID, or if sensitive secrets were accessed or exfiltration is suspected.
- Harden by enforcing least-privilege RBAC, requiring peer approval for RBAC changes, restricting workload mutations via GitOps-only service accounts, and using admission policies to deny privileged pods, hostPath mounts, and unapproved registries.
"""
references = [
    "https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control",
]
risk_score = 47
rule_id = "3c82bf84-5941-495b-ac41-0302f28e1a90"
severity = "medium"
tags = [
    "Data Source: Kubernetes",
    "Data Source: Kubernetes API Server Audit Logs",
    "Domain: Containers",
    "Domain: Kubernetes",
    "Platform: Kubernetes",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
    "Rule Type: Event Correlation (EQL)",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
sequence by user.name with maxspan=5m
  [any where data_stream.dataset == "kubernetes.audit_logs" and
   `kubernetes.audit.annotations.authorization_k8s_io/decision` == "allow" and
    kubernetes.audit.objectRef.resource in ("roles", "clusterroles") and
    kubernetes.audit.verb in ("create", "update", "patch") and
    /* GitOps controllers reconcile RBAC then workloads in the same window */
    not user.name in (
      "system:serviceaccount:flux-system:kustomize-controller",
      "system:serviceaccount:flux-system:helm-controller",
      "system:serviceaccount:flux-system:source-controller"
    )]
  [any where data_stream.dataset == "kubernetes.audit_logs" and
   `kubernetes.audit.annotations.authorization_k8s_io/decision` == "allow" and
    kubernetes.audit.objectRef.resource in ("daemonsets", "deployments", "cronjobs") and
    kubernetes.audit.verb in ("create", "patch") and
    /* reduce control-plane / bootstrap noise */
    not kubernetes.audit.user.groups == "system:masters"
  ]
'''

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

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

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

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

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

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

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

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

[metadata]
creation_date = "2020/11/19"
integration = ["o365"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies the deletion of an anti-phishing policy in Microsoft 365. By default, Microsoft 365 includes built-in
features that help protect users from phishing attacks. Anti-phishing polices increase this protection by refining
settings to better detect and prevent attacks.
"""
false_positives = [
    """
    An anti-phishing policy may be deleted by a system or network administrator. Verify that the configuration change
    was expected. Exceptions can be added to this rule to filter expected behavior.
    """,
]
from = "now-9m"
index = ["logs-o365.audit-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "M365 Exchange Anti-Phish Policy Deleted"
note = """## Triage and analysis

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

### Investigating M365 Exchange Anti-Phish Policy Deleted

Microsoft 365's anti-phishing policies enhance security by fine-tuning detection settings to thwart phishing attacks. Adversaries may delete these policies to weaken defenses, facilitating unauthorized access. The detection rule monitors audit logs for successful deletions of anti-phishing policies, signaling potential malicious activity by identifying specific actions and outcomes associated with policy removal.

### Possible investigation steps

- Review the audit logs for the specific event.action "Remove-AntiPhishPolicy" to identify the user account responsible for the deletion.
- Check the event.outcome field to confirm the success of the policy deletion and gather additional context from related logs around the same timestamp.
- Investigate the user account's recent activities in Microsoft 365 to identify any other suspicious actions or anomalies, such as unusual login locations or times.
- Assess whether the user account has been compromised by checking for any unauthorized access attempts or changes in account settings.
- Evaluate the impact of the deleted anti-phishing policy by reviewing the organization's current phishing protection measures and any recent phishing incidents.
- Coordinate with the IT security team to determine if the policy deletion was authorized or part of a legitimate change management process.

### False positive analysis

- Routine administrative actions may trigger the rule if IT staff regularly update or remove outdated anti-phishing policies. To manage this, create exceptions for known administrative accounts performing these actions.
- Scheduled policy reviews might involve the removal of policies as part of a legitimate update process. Document these schedules and exclude them from triggering alerts by setting time-based exceptions.
- Automated scripts used for policy management can inadvertently cause false positives. Identify and whitelist these scripts to prevent unnecessary alerts.
- Changes in organizational policy that require the removal of certain anti-phishing policies can be mistaken for malicious activity. Ensure that such changes are communicated and logged, and adjust the rule to recognize these legitimate actions.
- Test environments where policies are frequently added and removed for validation purposes can generate false positives. Exclude these environments from the rule to avoid confusion.

### Response and remediation

- Immediately isolate the affected user accounts and systems to prevent further unauthorized access or data exfiltration.
- Recreate the deleted anti-phishing policy using the latest security guidelines and ensure it is applied across all relevant user groups.
- Conduct a thorough review of recent email activity and logs for the affected accounts to identify any phishing emails that may have bypassed security measures.
- Reset passwords for affected accounts and enforce multi-factor authentication (MFA) to enhance account security.
- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
- Escalate the incident to the incident response team if there is evidence of broader compromise or if sensitive data has been accessed.
- Implement enhanced monitoring and alerting for similar actions in the future to quickly detect and respond to any further attempts to delete security policies.

## Setup

The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://docs.microsoft.com/en-us/powershell/module/exchange/remove-antiphishpolicy?view=exchange-ps",
    "https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/set-up-anti-phishing-policies?view=o365-worldwide",
]
risk_score = 47
rule_id = "d68eb1b5-5f1c-4b6d-9e63-5b6b145cd4aa"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: Microsoft 365",
    "Use Case: Configuration Audit",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:"Remove-AntiPhishPolicy" and event.outcome:success
'''


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

[[rule.threat.technique]]
id = "T1484"
name = "Domain or Tenant Policy Modification"
reference = "https://attack.mitre.org/techniques/T1484/"

[[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 = "2026/01/22"
integration = ["wiz"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
This alert identifies assets with an elevated number of vulnerabilities reported by Wiz, potentially indicating weak security posture,
missed patching, or active exposure. The rule highlights assets with a high volume of distinct vulnerabilities, the presence of exploitable
vulnerabilities, or a combination of multiple severities, helping prioritize assets that pose increased risk.
"""
from = "now-24h"
interval = "5m"
language = "esql"
license = "Elastic License v2"
name = "Multiple Vulnerabilities by Asset via Wiz"
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 Multiple Vulnerabilities by Asset via Wiz

This alert identifies assets with an elevated number of vulnerabilities reported by Wiz, potentially indicating weak security posture, missed patching, or active exposure. The rule highlights assets with a high volume of distinct vulnerabilities, the presence of exploitable vulnerabilities, or a combination of multiple severities, helping prioritize assets that pose increased risk.

### Possible investigation steps

- Review the affected asset details using `wiz.vulnerability.vulnerable_asset.name` and `wiz.vulnerability.vulnerable_asset.id` to confirm asset ownership, criticality, and exposure (e.g., internet-facing, production).
- Examine the list of detected vulnerabilities using `Esql.vuln_id_values` to identify known high-risk or widely exploited CVEs.
- Assess vulnerability severity distribution via `Esql.vuln_severity_values`, focusing on assets with multiple severity levels or repeated high/critical findings.
- Determine whether any vulnerabilities have known exploits by validating `wiz.vulnerability.has_exploit`, prioritizing those assets for immediate remediation.
- Cross-check recent patching, configuration changes, or deployment activity on the asset to identify potential gaps or misconfigurations.

### False positive analysis

- Assets undergoing initial onboarding, scanning expansion, or configuration changes may temporarily report a high volume of findings.
- Vulnerability aggregation may include informational or low-impact findings that inflate counts without representing immediate risk.
- Duplicate or closely related vulnerabilities affecting shared packages or libraries may appear as multiple findings for the same root cause.
- Test, lab, or non-production assets may legitimately tolerate higher vulnerability counts depending on risk acceptance.

### Response and remediation

- Prioritize remediation for assets with exploitable vulnerabilities or multiple high/critical severity findings.
- Apply missing patches, updates, or configuration fixes according to asset criticality and exposure.
- Implement compensating controls (e.g., network segmentation, access restrictions) if immediate patching is not feasible.
- Validate remediation by re-scanning the asset in Wiz to confirm vulnerability reduction.
- Review vulnerability management processes to prevent recurrence, including patch SLAs, asset ownership, and exposure monitoring."""
risk_score = 99
rule_id = "6fcb4fe4-ac74-449d-855b-2bbd5c51c476"
severity = "critical"
tags = ["Use Case: Vulnerability", "Rule Type: Higher-Order Rule", "Resources: Investigation Guide", "Data Source: Wiz"]
timestamp_override = "event.ingested"
type = "esql"

query = '''
FROM logs-wiz.vulnerability-*

| WHERE data_stream.dataset == "wiz.vulnerability" and event.category == "vulnerability" and
        wiz.vulnerability.vulnerable_asset.name is not null and
        wiz.vulnerability.vulnerable_asset.id is not null
| stats Esql.count_distinct_vuln_id = COUNT_DISTINCT(wiz.vulnerability.id),
        Esql.count_distinct_vuln_severity = COUNT_DISTINCT(wiz.vulnerability.cvss_severity),
        Esql.count_has_exploit = COUNT(wiz.vulnerability.has_exploit),
        Esql.vuln_id_values = VALUES(wiz.vulnerability.id),
        Esql.vuln_severity_values = VALUES(wiz.vulnerability.cvss_severity) by wiz.vulnerability.vulnerable_asset.name, wiz.vulnerability.vulnerable_asset.id
| eval concat_vuln_severity_values = MV_CONCAT(Esql.vuln_severity_values, ",")
| where Esql.count_distinct_vuln_id >= 10 or
        (Esql.count_has_exploit >= 1 and Esql.count_distinct_vuln_id >= 3) or
        (concat_vuln_severity_values like "*High*" and Esql.count_distinct_vuln_id >= 3) or
        (concat_vuln_severity_values like "*Critical*" and Esql.count_distinct_vuln_id >= 3)
| Keep wiz.vulnerability.vulnerable_asset.name, wiz.vulnerability.vulnerable_asset.id, Esql.*
'''
references = ["https://www.elastic.co/docs/reference/integrations/wiz#vulnerability"]

[metadata]
creation_date = "2026/05/01"
integration = ["cloud_defend"]
maturity = "production"
min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
min_stack_version = "9.3.0"
updated_date = "2026/05/01"

[rule]
author = ["Elastic"]
description = """
Identifies suspicious usage of unshare to manipulate system namespaces. Unshare can be utilized to escalate privileges
or escape container security boundaries. Threat actors have utilized this binary to allow themselves to escape to the
host and access other resources or escalate privileges.
"""
from = "now-9m"
index = ["logs-cloud_defend.process*"]
language = "eql"
license = "Elastic License v2"
name = "Namespace Manipulation Using Unshare in a Container"
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 Namespace Manipulation Using Unshare in a Container

The `unshare` command in Linux is used to create new namespaces, isolating processes from the rest of the system. This isolation is crucial for containerization and security. However, attackers can exploit `unshare` to break out of containers or elevate privileges by creating namespaces that bypass security controls. The detection rule identifies suspicious `unshare` executions by monitoring process starts, filtering out benign parent processes, and focusing on unusual usage patterns, thus highlighting potential misuse.

### Possible investigation steps

- Review the process tree to understand the context of the unshare execution, focusing on the parent process and any child processes spawned by unshare.
- Investigate the user account associated with the unshare execution to determine if it is a legitimate user or potentially compromised.
- Examine the command-line arguments used with unshare to identify any unusual or suspicious options that may indicate an attempt to bypass security controls.
- Check for any recent changes or anomalies in the system logs around the time of the unshare execution to identify potential indicators of compromise or privilege escalation attempts.
- Correlate the unshare event with other security alerts or logs to determine if it is part of a larger attack pattern or campaign.

### False positive analysis

- System management tools like udevadm and systemd-udevd may invoke unshare as part of their normal operations. These should be excluded by ensuring the rule filters out processes with these as parent executables.
- Snap package management can trigger unshare during its operations. Exclude processes where the arguments include /usr/bin/snap to prevent unnecessary alerts.
- Java applications might occasionally use unshare for legitimate purposes. Exclude processes with java as the parent name to reduce false positives.
- Custom scripts or administrative tasks that use unshare for legitimate namespace management should be reviewed and, if deemed safe, added to the exclusion list to prevent repeated alerts.

### Response and remediation

- Immediately isolate the affected system to prevent further unauthorized access or lateral movement within the network.
- Terminate any suspicious processes associated with the `unshare` command that do not have legitimate parent processes or arguments, as identified in the detection query.
- Conduct a thorough review of system logs and process trees to identify any additional unauthorized or suspicious activities that may have occurred in conjunction with the `unshare` execution.
- Revoke any unauthorized access or privileges that may have been granted as a result of the namespace manipulation, ensuring that all user and process permissions are appropriately restricted.
- Restore the affected system from a known good backup if any unauthorized changes or damage to the system integrity are detected.
- Implement additional monitoring and alerting for unusual `unshare` usage patterns to enhance detection capabilities and prevent future occurrences.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised."""
references = ["https://man7.org/linux/man-pages/man1/unshare.1.html"]
risk_score = 47
rule_id = "9e5dbd3b-5e19-4648-a1cf-c2649c91b015"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "Domain: Container",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Data Source: Elastic Defend for Containers",
    "Resources: Investigation Guide"
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where event.type == "start" and event.action == "exec" and
process.name == "unshare" and container.id like "?*" and not (
  process.parent.executable: ("/usr/bin/udevadm", "*/lib/systemd/systemd-udevd", "/usr/bin/unshare") or
  (process.args == "/usr/bin/snap" and not process.parent.name in ("zz-proxmox-boot", "java")) or
  process.parent.args like (
    "/etc/kernel/postinst.d/zz-proxmox-boot", "/opt/openssh/sbin/sshd", "/usr/sbin/sshd",
    "/snap/*", "/home/*/.local/share/JetBrains/Toolbox/*"
  ) or
 (process.args == "--propagation" and process.args == "private" and process.args like "/etc/kernel/post*.d/zz-proxmox-boot") or 
 (process.args == "--fork" and process.args == "--kill-child") or 
  process.args like ("/usr/bin/os-prober", "/usr/bin/linux-boot-prober", "/opt/SIGOS/sitedata/exec/*")
)
'''

[[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]]
id = "T1611"
name = "Escape to Host"
reference = "https://attack.mitre.org/techniques/T1611/"

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

[metadata]
creation_date = "2026/07/02"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/07/06"

[rule]
author = ["Elastic"]
description = """
Detects network connections originating from a binary located in a potentially suspicious location, followed by a file
creation event. This behavior is consistent with C2 agents such as Poseidon and Athena, connecting to a C2 framework
such as Mythic. The agent polls the C2 for commands through a web request, after which the command gets executed.
"""
from = "now-9m"
index = ["logs-endpoint.events.network*", "logs-endpoint.events.file*"]
language = "eql"
license = "Elastic License v2"
name = "Network Connection Followed by File Creation"
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 Network Connection Followed by File Creation

This rule spots a Linux process running from an unusual writable directory that makes an outbound connection and then creates a file within seconds, a pattern that often marks an active implant receiving tasks and staging follow-on activity. Attackers launch a loader from /dev/shm or /tmp, poll a remote web-based command server, and immediately drop a script or renamed payload for execution or persistence.

### Possible investigation steps

- Review the process ancestry and launch context for the binary in the writable directory to determine whether it originated from a user session, script, scheduled task, package operation, or remote execution mechanism.
- Inspect the external destination's reputation, ownership, protocol details, and whether other hosts contacted it at similar times to distinguish approved software behavior from likely command-and-control traffic.
- Examine the created file's location, type, hash, contents, permissions, and any immediate chmod, rename, or execution activity to assess whether it is a staged payload, script, or persistence artifact.
- Build a concise timeline around the alert to identify preceding download, decode, or unpack actions and any follow-on child processes, credential access attempts, or lateral movement from the same host.
- Search the environment for the same executable hash, destination, or dropped artifact on other systems and contain the host if you observe repeated beaconing, additional suspicious file creation, or evidence of execution.

### False positive analysis

- A legitimate software installer, updater, or bootstrap script launched from /tmp or /var/tmp can contact an external repository and immediately create unpacked files; verify the parent process, initiating user, shell history, and whether the destination IP and dropped files align with an approved installation or update at that time.
- An administrator or automation job may execute a temporary script from /dev/shm or /run/user to fetch remote content and write logs, configuration, or cache files; confirm the activity matches a scheduled task or provisioning change and inspect the created file paths and script contents for expected benign output.

### Response and remediation

- Isolate the affected Linux host from the network except for approved management access, kill the suspicious process running from the writable directory, quarantine the binary and any files it created, and block the contacted external IP or domain at the firewall, proxy, and DNS layers.
- Remove attacker footholds by deleting malicious systemd services, cron jobs, shell profile modifications, SSH authorized_keys entries, and any copied or renamed payloads the implant placed under writable paths or startup locations, after preserving forensic copies.
- Reset potentially exposed access by rotating passwords, SSH keys, API tokens, and service credentials used on the host, especially if the process ran as root, touched authentication files, or dropped scripts and configuration files that may contain secrets.
- Restore the system to a known-good state by reimaging or rebuilding the host from a trusted baseline when the binary or dropped files executed, then validate package integrity, startup items, and critical application data before reconnecting it to production.
- Escalate immediately to incident response if the same executable hash, outbound destination, or dropped artifact appears on additional hosts, or if you identify privilege escalation, credential theft, persistence in multiple locations, or attempted lateral movement.
- Harden the environment by blocking execution from /tmp, /dev/shm, and other writable directories where feasible, tightening egress rules to approved destinations, enforcing application allowlisting, and improving monitoring for new outbound beacons followed by file creation.
"""
risk_score = 21
rule_id = "01c1e353-9d86-4344-abdf-523ab80c6f08"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

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

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

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Command and Control",
    "Tactic: Execution",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
type = "eql"
query = '''
sequence by host.id, process.entity_id with maxspan=5s
  [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and
  process.executable like (
    "/boot/*", "/dev/shm/*", "/tmp/*", "/var/tmp/*", "/var/log/*", "/var/run/user/*", "/run/user/*"
  ) and
  not (
    destination.ip == null or
    destination.ip == "0.0.0.0" or 
    cidrmatch(
      destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12",
      "192.0.0.0/24", "192.0.0.0/29","192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32",
      "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24",
      "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", "192.175.48.0/24",
      "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10",
      "FF00::/8", "FC00::/7"
    )
  )]
  [file where host.os.type == "linux" and event.type == "creation" and process.executable like (
    "/boot/*", "/dev/shm/*", "/tmp/*", "/var/tmp/*", "/var/log/*", "/boot/*", "/var/run/user/*", "/run/user/*"
  ) and
  not (
    file.name like "tmp*" or file.extension in ("sqlite-journal", "db-journal", "lockfile", "tmp") or
    file.path like (
      "/loki/wal/*", "/dev/shm/.org.chromium.Chromium.*", "/opt/rapid7/nexpose/*",
      "/usr/local/ltechagent*", "/var/lib/cloudendure/agent_keystore_temp", "/var/cache/yum/*",
      "/run/aws-node/ipam.json.tmp*", "/run/systemd/journal/streams/.*"
    ) or
    (process.executable == "/tmp/terraform" and file.path like "/tmp/terraform-provider*") or 
    process.name in ("podman", "minikube", "logrotate", "java", "aws-k8s-agent", "grafana", "postman") or
    process.executable : (
      "/etc/cron.daily/logrotate", "/etc/update-motd.d/50-motd-news", "/etc/cron.hourly/0yum-hourly.cron",
      "/etc/cron.hourly/BitdefenderRedline", "/tmp/token_handler", "/tmp/.sentry-cli*.exe", 
      "/etc/cron.daily/0yum-daily.cron", "/etc/init.d/fortiedr"
    )
  )]
'''

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

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

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

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

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

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

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

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

[metadata]
creation_date = "2023/08/22"
integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike", "windows"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
Identifies the modification of the Microsoft Office "Office Test" Registry key, a registry location that can be used to
specify a DLL which will be executed every time an MS Office application is started. Attackers can abuse this to gain
persistence on a compromised host.
"""
from = "now-9m"
index = [
    "logs-endpoint.events.registry-*",
    "logs-m365_defender.event-*",
    "endgame-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-crowdstrike.fdr*",
    "logs-windows.sysmon_operational-*",
]
language = "eql"
license = "Elastic License v2"
name = "Office Test Registry Persistence"
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 Office Test Registry Persistence

The Office Test Registry key in Windows environments allows specifying a DLL to execute whenever an Office application starts, providing a mechanism for legitimate customization. However, adversaries can exploit this for persistence by loading malicious DLLs. The detection rule monitors modifications to this registry path, excluding deletions, to identify potential abuse, leveraging data from various security sources to flag suspicious activity.

### Possible investigation steps

- Review the registry event details to identify the specific DLL path that was added or modified in the Office Test Registry key.
- Check the file properties and digital signature of the DLL specified in the registry modification to determine its legitimacy.
- Investigate the source of the registry modification by correlating with user activity logs to identify which user account made the change.
- Analyze recent process execution logs for any Office applications to detect if the suspicious DLL has been loaded or executed.
- Cross-reference the DLL and associated registry modification with threat intelligence sources to check for known malicious indicators.
- Examine the system for additional signs of compromise, such as unusual network connections or other persistence mechanisms, to assess the scope of potential intrusion.

### False positive analysis

- Legitimate software installations or updates may modify the Office Test Registry key as part of their setup process. Users can create exceptions for known software vendors or specific applications that are frequently updated.
- System administrators might use scripts or management tools that modify the registry for configuration purposes. Identify and exclude these trusted scripts or tools from triggering alerts.
- Customization by IT departments for legitimate business needs can lead to registry modifications. Document and whitelist these customizations to prevent false positives.
- Security software or monitoring tools might interact with the registry as part of their normal operations. Verify and exclude these interactions if they are known to be safe and necessary for system functionality.

### Response and remediation

- Immediately isolate the affected host from the network to prevent further spread or communication with potential command and control servers.
- Use endpoint detection and response (EDR) tools to terminate any suspicious processes associated with the malicious DLL identified in the registry path.
- Remove the malicious DLL entry from the Office Test Registry key to prevent it from executing on future Office application startups.
- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or remnants.
- Review recent user activity and system logs to identify any unauthorized access or changes that may have led to the registry modification, and reset credentials if necessary.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
- Implement enhanced monitoring and alerting for similar registry modifications across the network to detect and respond to future attempts promptly."""
references = [
    "https://unit42.paloaltonetworks.com/unit42-technical-walkthrough-office-test-persistence-method-used-in-recent-sofacy-attacks/",
]
risk_score = 21
rule_id = "14dab405-5dd9-450c-8106-72951af2391f"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Data Source: Elastic Endgame",
    "Data Source: Microsoft Defender XDR",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
    "Data Source: Sysmon",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
registry where host.os.type == "windows" and event.action != "deletion" and
    registry.path : "*\\Software\\Microsoft\\Office Test\\Special\\Perf\\*"
'''

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 Registry Events](https://ela.st/sysmon-event-reg-setup)
"""


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1137"
name = "Office Application Startup"
reference = "https://attack.mitre.org/techniques/T1137/"
[[rule.threat.technique.subtechnique]]
id = "T1137.002"
name = "Office Test"
reference = "https://attack.mitre.org/techniques/T1137/002/"



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


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

[rule]
description = """
Detects when a new OsaScript download cradle is spawned as a backgrounded process to launch a new callback. The Apfell
agent payload utilizes this method in order to spawn additional payload callbacks.
"""
id = "c8e816ab-360f-4608-aebf-a056437c7df0"
license = "Elastic License v2"
name = "OsaScript Download Cradle Spawned"
os_list = ["macos"]
reference = [
    "https://github.com/MythicAgents/apfell/blob/master/documentation-payload/apfell/commands/spawn_download_cradle.md",
    "https://github.com/MythicAgents/apfell/",
]
version = "1.0.9"

query = '''
sequence by process.entity_id with maxspan=15s
[process where event.type == "start" and event.action == "exec" and 
 process.name == "osascript" and process.args == "-l" and 
 process.args like~ "JavaScript" and process.args == "-e" and
 process.parent.name == "osascript"]
[network where event.type == "start" and process.name == "osascript"]
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1008"
name = "Fallback Channels"
reference = "https://attack.mitre.org/techniques/T1008/"


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

[internal]
min_endpoint_version = "8.16.0"

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

[rule]
author = ["Elastic"]
description = """
Identifies the creation of a new port forwarding rule. An adversary may abuse this technique to bypass network
segmentation restrictions.
"""
from = "now-9m"
index = [
    "winlogbeat-*",
    "logs-endpoint.events.registry-*",
    "logs-windows.sysmon_operational-*",
    "endgame-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-m365_defender.event-*",
    "logs-crowdstrike.fdr*",
]
language = "eql"
license = "Elastic License v2"
name = "Port Forwarding Rule Addition"
note = """## Triage and analysis

### Investigating Port Forwarding Rule Addition

Network port forwarding is a mechanism to redirect incoming TCP connections (IPv4 or IPv6) from the local TCP port to any other port number, or even to a port on a remote computer.

Attackers may configure port forwarding rules to bypass network segmentation restrictions, using the host as a jump box to access previously unreachable systems.

This rule monitors the modifications to the `HKLM\\SYSTEM\\*ControlSet*\\Services\\PortProxy\\v4tov4\\` subkeys.

#### Possible investigation steps

- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
- Identify the user account that performed the action and whether it should perform this kind of action.
- Contact the account and system owners and confirm whether they are aware of this activity.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.
- Identify the target host IP address, check the connections originating from the host where the modification occurred, and inspect the credentials used.
  - Investigate suspicious login activity, such as unauthorized access and logins from outside working hours and unusual locations.

### False positive analysis

- This mechanism can be used legitimately. Analysts can dismiss the alert if the Administrator is aware of the activity and there are justifications for this configuration.
- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and command line conditions.

### Response and remediation

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

setup = """## Setup

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

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

### Additional data sources

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

- [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 Registry Events](https://ela.st/sysmon-event-reg-setup)
"""

references = [
    "https://www.fireeye.com/blog/threat-research/2019/01/bypassing-network-restrictions-through-rdp-tunneling.html",
]
risk_score = 47
rule_id = "3535c8bb-3bd5-40f4-ae32-b7cd589d5372"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Command and Control",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Crowdstrike",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
registry where host.os.type == "windows" and event.type == "change" and 
  registry.path : "*\\SYSTEM\\*ControlSet*\\Services\\PortProxy\\v4tov4\\*" and registry.data.strings != null
'''


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

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

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

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

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

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

[[rule.threat.technique]]
id = "T1112"
name = "Modify Registry"
reference = "https://attack.mitre.org/techniques/T1112/"

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