Elastic rules: 2b

[rule]
description = """
Identifies attemtps to call Windows memory management APIs from the Trusted App Runtime DLL tprtdll.dll. This may
indicate an attempt to execute syscalls from a trusted module while avoiding potential NTDLL hooks.
"""
id = "ed572422-cefc-496c-b59f-65d8c34b9ac4"
license = "Elastic License v2"
name = "API via Trusted App Runtime DLL"
os_list = ["windows"]
reference = [
    "https://github.com/whokilleddb/function-collections/blob/8ad66ca3276b8d1b1864552d0e09f32c56126ec5/winapi_alternatives/NtAllocateMemoryEx/main.c",
]
version = "1.0.3"

query = '''
api where process.Ext.api.name in ("VirtualAlloc", "VirtualProtect", "WriteProcessMemory","VirtualProtectEx", "VirtualAllocEx") and
 (
  process.thread.Ext.call_stack_summary like "tprtdll.dll|*" or

  (process.thread.Ext.call_stack_final_user_module.name == "Unbacked" and
   process.thread.Ext.call_stack_final_user_module.protection_provenance_path == "c:\\windows\\system32\\tprtdll.dll") or

   process.thread.Ext.call_stack_final_user_module.path == "c:\\windows\\system32\\tprtdll.dll"
  )
'''

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

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


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

[internal]
min_endpoint_version = "8.14.2"

[rule]
description = """
This rule monitors for attempts to clear logs using the "journalctl" command on Linux systems. Adversaries may use this
technique to cover their tracks by deleting or truncating log files, making it harder for defenders to investigate their
activities. The rule looks for the execution of "journalctl" with arguments that indicate log clearing actions, such as
"--vacuum-time", "--vacuum-size", or "--vacuum-files".
"""
id = "2f45b36f-a60d-46c9-9f82-eb80ab62ce7f"
license = "Elastic License v2"
name = "Attempt to Clear Logs via Journalctl"
os_list = ["linux"]
version = "1.0.1"

query = '''
process where event.type == "start" and event.action == "exec" and process.name == "journalctl" and
process.args like~ ("--vacuum-time=?s", "--vacuum-size=?M", "--vacuum-files=*") and
not (
  process.parent.args in ("/usr/lib/armbian/armbian-truncate-logs", "/root/innovasive_reverseproxy/backupscript/cleanup_hour.sh") or
  process.parent.executable == "/tmp/newroot/usr/bin/sudo"
)
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1070"
name = "Indicator Removal"
reference = "https://attack.mitre.org/techniques/T1070/"
[[threat.technique.subtechnique]]
id = "T1070.002"
name = "Clear Linux or Mac System Logs"
reference = "https://attack.mitre.org/techniques/T1070/002/"


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



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

[internal]
min_endpoint_version = "7.15.0"

[metadata]
creation_date = "2026/08/17"
integration = ["network_traffic"]
maturity = "production"
updated_date = "2026/08/17"

[rule]
author = ["Elastic"]
description = """
Identifies HTTP requests to Azure WireServer (168.63.129.16) for GoalState, certificates, versions, or HostGAPlugin
vmSettings that do not use a known guest-agent user agent. These requests retrieve transport certificates and extension
protectedSettings, including embedded SAS URLs. Azure Linux Agent, Windows guest agent, and related platform UAs are
excluded. Requests with no user agent are also excluded; that pattern is common for the Windows guest agent.
"""
false_positives = [
    """
    Custom health checks that call HostGAPlugin /versions or /vmSettings with curl. Exclude the specific user agent or
    host group after validating the script.
    """,
]
from = "now-9m"
index = ["logs-network_traffic.http*"]
language = "eql"
license = "Elastic License v2"
name = "Azure WireServer HTTP Request from Unexpected User Agent"
note = """## Triage and analysis

### Investigating Azure WireServer HTTP Request from Unexpected User Agent

Network Packet Capture with HTTP decoding on ports 80 and 32526 shows the URI that Elastic Defend network events
lack. The match is the WireServer path or query, not a scripting-tool user-agent allowlist.

- `url.query` contains `comp=versions` (discovery)
- `url.query` contains `comp=goalstate` (incarnation, container, extension list, statusUploadBlob pointer)
- `url.query` contains `comp=certificates` (often with request header `x-ms-guest-agent-public-x509-cert`)
- `destination.port == 32526` and `url.path` in `/versions`, `/vmSettings`

Excluded user agents from lab guest-agent traffic: `WALinuxAgent/*`, `VMAgent/*`, `Python-urllib/*`,
`cpprestsdk/*`, `ACMS/*`, and a missing user agent (Windows guest agent). Curl and Windows PowerShell are not
excluded and will fire.

`/vmSettings` response bodies are often dropped when they exceed keyword `ignore_above`. The URI, port, and user
agent are sufficient. Do not enable body capture to chase this rule.

### Possible investigation steps

- Confirm `url.path`, `url.query`, `destination.port`, and `user_agent.original`.
- GoalState (`comp=goalstate`) is reconnaissance; `comp=certificates` means the client presented a transport
  certificate. Look on the host for `openssl req ... LinuxTransport` or a stolen `.crt`/`.key`.
- Correlate with endpoint network events from the same `host.name` to `168.63.129.16` and process start events for
  openssl cms decrypt.
- Search StorageRead platform logs for anonymous or SAS GetBlob against the same storage account after the scrape.

### False positive analysis

- Administrative curl or other non-agent clients against WireServer during incident response. Exclude the specific
  user agent or host after the change window.
- A new Microsoft guest-agent build with an unfamiliar user agent will fire until that UA is excluded.
- Omitting the user agent looks like the Windows guest agent and is not matched. Do not treat a missing UA as
  suspicious on its own.

### Response and remediation

- Isolate the VM, rotate secrets recovered from vmSettings, and review extension protectedSettings.
- Enable Metadata Security Protocol in audit or enforce mode to restrict WireServer callers.
"""
references = [
    "https://cybercx.com.au/blog/azure-ssrf-metadata/",
    "https://www.netspi.com/blog/technical-blog/cloud-pentesting/decrypting-vm-extension-settings-with-azure-wireserver/",
    "https://cloud.google.com/blog/topics/threat-intelligence/escalating-privileges-azure-kubernetes-services",
    "https://learn.microsoft.com/en-us/azure/virtual-network/what-is-ip-address-168-63-129-16",
]
risk_score = 47
rule_id = "359b5925-a625-4803-90d2-19e44a37d98e"
setup = """## Setup

Deploy the [Network Packet Capture](https://www.elastic.co/docs/reference/integrations/network_traffic) integration
via Fleet on Azure virtual machines. Default HTTP port lists do not include HostGAPlugin.

Required integration settings:

- Enable **Capture HTTP Traffic**.
- Set HTTP ports to include **80** (WireServer GoalState, versions, certificates) and **32526** (HostGAPlugin
  `/versions`, `/vmSettings`). Without 32526, HostGAPlugin requests are invisible.
- Enable **Monitor Processes** so HTTP events include `process.*` when available.
- Optional: **Send all headers** to retain `x-ms-version` and `x-ms-guest-agent-public-x509-cert` for investigation.
  The rule matches URI, port, and user agent, not the certificate PEM.
- Do not enable request or response body capture for this rule. `/vmSettings` bodies are large and often dropped;
  other WireServer XML is not required for the match.
"""
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Network",
    "OS: Linux",
    "OS: Windows",
    "Platform: Azure",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Tactic: Discovery",
    "Data Source: Network Packet Capture",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
network where event.module == "network_traffic" and
destination.ip == "168.63.129.16" and
user_agent.original != null and
not user_agent.original : (
  "WALinuxAgent*",
  "VMAgent*",
  "Python-urllib*",
  "cpprestsdk*",
  "ACMS/*"
) and
(
  url.query : ("*comp=versions*", "*comp=goalstate*", "*comp=certificates*") or
  (destination.port == 32526 and url.path : ("/versions", "/vmSettings"))
)
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1552"
name = "Unsecured Credentials"
reference = "https://attack.mitre.org/techniques/T1552/"
[[rule.threat.technique.subtechnique]]
id = "T1552.005"
name = "Cloud Instance Metadata API"
reference = "https://attack.mitre.org/techniques/T1552/005/"



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


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

[rule]
description = """
Detects when Osascript accesses crypto wallet or web browser files on a macOS system like crypto wallet files, or web
browser cookies.
"""
id = "b4428697-1df8-4979-ac49-7183374eee6c"
license = "Elastic License v2"
name = "Crypto Wallet or Web Browser File Access via Osascript"
os_list = ["macos"]
version = "1.0.2"

query = '''
file where event.action == "open" and (process.name == "osascript" or Effective_process.name == "osascript") and 
 (file.path like~ ("/Users/*/.electrum/*",
                   "/Users/*/Library/Application_Support/*/Default/Extensions/*",
                   "/Users/*/Library/Application Support/*/Default/Local Extension Settings/*",
                   "/Users/*/Library/Application Support/Electrum/*",
                   "/Users/*/Library/Application Support/Exodus/*", 
                   "/Users/*/Library/Application Support/Coinomi/*",
                   "/Users/*/Library/Application Support/Atomic/*",
                   "/Users/*/Library/Application Support/@trezor/*",
                   "/Users/*/Library/Application Support/Ledger Live/*",
                   "/Users/*/Library/Application Support/WasabiWallet/*",
                   "/Users/*/Monero/*",
                   "/Users/*/Library/Application Support/Bitcoin/*",
                   "/Users/*/Library/Application Support/Litecoin/*",
                   "/Users/*/Library/Application Support/DashCore/*",
                   "/Users/*/Library/Application Support/ElectronCash/*",
                   "/Users/*/Library/Application Support/Guarda/*",
                   "/Users/*/Library/Application Support/Dogecoin/*",
                   "/Users/*/Library/Application Support/BraveSoftware/Brave-Browser/BraveWallet/*",
                   "/Users/*/Library/Application Support/BraveSoftware/Brave-Browser/Default/Local Extension Settings/pgojbichloddijphfmfhhfolimnhjklk/*",
                   "/Users/*/Library/Application Support/Firefox/Profiles/*/extensions/*") or
   file.name like~ ("cookies.sqlite", 
                    "key?.db", 
                    "logins.json", 
                    "Cookies", 
                    "Cookies.binarycookies", 
                    "Login Data"))
'''

min_endpoint_version = "8.11.1"
optional_actions = []
[[actions]]
action = "kill_process"
field = "Effective_process.entity_id"
state = 0

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1552"
name = "Unsecured Credentials"
reference = "https://attack.mitre.org/techniques/T1552/"
[[threat.technique.subtechnique]]
id = "T1552.001"
name = "Credentials In Files"
reference = "https://attack.mitre.org/techniques/T1552/001/"



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

[internal]
min_endpoint_version = "8.11.1"

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

[rule]
author = ["Austin Songer"]
description = "Identifies that a user has deleted an unusually large volume of files as reported by Microsoft Cloud App Security."
false_positives = ["Users or System Administrator cleaning out folders."]
from = "now-9m"
index = ["logs-o365.audit-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "Deprecated - M365 Security Compliance Unusual Volume of File Deletion"
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 Deprecated - M365 Security Compliance Unusual Volume of File Deletion

Microsoft 365's cloud environment facilitates file storage and collaboration, but its vast data handling capabilities can be exploited by adversaries for data destruction. Attackers may delete large volumes of files to disrupt operations or cover their tracks. The detection rule leverages audit logs to identify anomalies in file deletion activities, flagging successful, unusual deletion volumes as potential security incidents, thus enabling timely investigation and response.

### Possible investigation steps

- Review the audit logs for the specific user associated with the alert to confirm the volume and context of the file deletions, focusing on entries with event.action:"Unusual volume of file deletion" and event.outcome:success.
- Correlate the timestamps of the deletion events with other activities in the user's account to identify any suspicious patterns or anomalies, such as unusual login locations or times.
- Check for any recent changes in user permissions or roles that might explain the ability to delete a large volume of files, ensuring these align with the user's typical responsibilities.
- Investigate any recent security alerts or incidents involving the same user or related accounts to determine if this activity is part of a broader attack or compromise.
- Contact the user or their manager to verify if the deletions were intentional and authorized, and gather any additional context that might explain the activity.
- Assess the impact of the deletions on business operations and data integrity, and determine if any recovery actions are necessary to restore critical files.

### False positive analysis

- High-volume legitimate deletions during data migration or cleanup projects can trigger false positives. To manage this, create exceptions for users or groups involved in these activities during the specified time frame.
- Automated processes or scripts that perform bulk deletions as part of routine maintenance may be flagged. Identify these processes and whitelist them to prevent unnecessary alerts.
- Users with roles in data management or IT support may regularly delete large volumes of files as part of their job responsibilities. Establish a baseline for these users and adjust the detection thresholds accordingly.
- Temporary spikes in file deletions due to organizational changes, such as department restructuring, can be mistaken for malicious activity. Monitor these events and temporarily adjust the rule parameters to accommodate expected changes.
- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded from alerts, maintaining the effectiveness of the detection rule.

### Response and remediation

- Immediately isolate the affected user account to prevent further unauthorized file deletions. This can be done by disabling the account or changing the password.
- Review the audit logs to identify the scope of the deletion and determine if any critical or sensitive files were affected. Restore these files from backups if available.
- Conduct a thorough review of the affected user's recent activities to identify any other suspicious actions or potential indicators of compromise.
- Escalate the incident to the security operations team for further investigation and to determine if the deletion is part of a larger attack or breach.
- Implement additional monitoring on the affected account and similar high-risk accounts to detect any further unusual activities.
- Review and update access controls and permissions to ensure that users have the minimum necessary access to perform their job functions, reducing the risk of large-scale deletions.
- Coordinate with the IT and security teams to conduct a post-incident review, identifying any gaps in the response process and implementing improvements to prevent recurrence.

## 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/cloud-app-security/anomaly-detection-policy",
    "https://docs.microsoft.com/en-us/cloud-app-security/policy-template-reference",
]
risk_score = 47
rule_id = "b2951150-658f-4a60-832f-a00d1e6c6745"
severity = "medium"
tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Configuration Audit", "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 event.action:"Unusual volume of file deletion" and event.outcome:success
'''


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


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

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

[rule]
author = ["Elastic"]
description = """
Identifies when guest access is enabled in Microsoft Teams. Guest access in Teams allows people outside the organization
to access teams and channels. An adversary may enable guest access to maintain persistence in an environment.
"""
false_positives = [
    """
    Teams guest access may be enabled 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 = "Deprecated - M365 Teams Guest Access Enabled"
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 Deprecated - M365 Teams Guest Access Enabled

Microsoft Teams allows organizations to collaborate with external users through guest access, facilitating communication and teamwork. However, adversaries can exploit this feature to gain persistent access to sensitive environments by enabling guest access without authorization. The detection rule monitors audit logs for specific configurations that indicate guest access has been enabled, helping identify unauthorized changes and potential security breaches.

### Possible investigation steps

- Review the audit logs to confirm the event.action "Set-CsTeamsClientConfiguration" was successfully executed with the parameter o365.audit.Parameters.AllowGuestUser set to True.
- Identify the user account responsible for enabling guest access by examining the event logs for the user ID or account name associated with the action.
- Check the user's activity history to determine if there are any other suspicious actions or patterns, such as changes to other configurations or unusual login times.
- Investigate the context of the change by reviewing any related communications or requests that might justify enabling guest access, ensuring it aligns with organizational policies.
- Assess the potential impact by identifying which teams and channels now have guest access enabled and evaluate the sensitivity of the information accessible to external users.
- Contact the user or their manager to verify if the change was authorized and necessary, and document their response for future reference.

### False positive analysis

- Legitimate collaboration with external partners may trigger alerts when guest access is enabled for business purposes. To manage this, create exceptions for known and approved external domains or specific projects that require guest access.
- Routine administrative actions by IT staff to enable guest access for specific teams or channels can be mistaken for unauthorized changes. Implement a process to log and approve such changes internally, and exclude these from triggering alerts.
- Automated scripts or third-party applications that configure Teams settings, including guest access, might cause false positives. Identify and whitelist these scripts or applications to prevent unnecessary alerts.
- Changes made during scheduled maintenance windows can be misinterpreted as unauthorized. Define and exclude these time periods from monitoring to reduce false positives.

### Response and remediation

- Immediately disable guest access in Microsoft Teams by updating the Teams client configuration to prevent unauthorized external access.
- Conduct a thorough review of recent audit logs to identify any unauthorized changes or suspicious activities related to guest access settings.
- Notify the security team and relevant stakeholders about the potential breach to ensure awareness and initiate further investigation.
- Revoke any unauthorized guest accounts that have been added to Teams to eliminate potential persistence mechanisms.
- Implement additional monitoring on Teams configurations to detect any future unauthorized changes to guest access settings.
- Escalate the incident to the organization's incident response team for a comprehensive investigation and to determine if further containment actions are necessary.
- Review and update access control policies to ensure that enabling guest access requires appropriate authorization and oversight.

## 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/skype/get-csteamsclientconfiguration?view=skype-ps",
]
risk_score = 47
rule_id = "5e552599-ddec-4e14-bad1-28aa42404388"
severity = "medium"
tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Configuration Audit", "Tactic: Persistence", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:o365.audit and event.provider:(SkypeForBusiness or MicrosoftTeams) and
event.category:web and event.action:"Set-CsTeamsClientConfiguration" and
o365.audit.Parameters.AllowGuestUser:True and event.outcome:success
'''


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

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

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

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

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

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

[metadata]
creation_date = "2025/03/04"
integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel", "cloud_defend"]
maturity = "production"
min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
min_stack_version = "9.3.0"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
This rule detects potential Docker socket enumeration activity by monitoring processes that attempt to interact with the
Docker socket file (/var/run/docker.sock). Docker socket enumeration is a common technique used by attackers to interact
with the Docker daemon and perform various operations, such as creating, starting, stopping, and removing containers.
Attackers may abuse Docker socket enumeration to gain unauthorized access to the host system, escalate privileges, or
move laterally within the environment.
"""
from = "now-9m"
index = [
    "auditbeat-*",
    "endgame-*",
    "logs-auditd_manager.auditd-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-cloud_defend.process*",
]
language = "eql"
license = "Elastic License v2"
name = "Docker Socket Enumeration"
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 Docker Socket Enumeration

Docker sockets facilitate communication between the Docker client and daemon, enabling container management. Adversaries exploit this by accessing the socket to control containers, potentially escalating privileges or moving laterally. The detection rule identifies suspicious processes interacting with the Docker socket, using specific commands, to flag unauthorized enumeration attempts.

### Possible investigation steps

- Review the process details to confirm the presence of suspicious commands interacting with the Docker socket, specifically looking for the use of tools like curl, socat, nc, netcat, ncat, or nc.traditional.
- Examine the command line arguments of the flagged process to understand the intent and scope of the interaction with the Docker socket, focusing on paths like /var/run/docker.sock or /run/docker.sock.
- Identify the user account under which the suspicious process was executed to assess if it has legitimate access to Docker resources or if it might be compromised.
- Check the historical activity of the involved user and process to determine if this behavior is anomalous or part of a known pattern.
- Investigate any recent changes or deployments in the Docker environment that might explain the interaction with the Docker socket, such as new container setups or updates.
- Correlate the alert with other security events or logs from the same host or network segment to identify potential lateral movement or privilege escalation attempts.

### False positive analysis

- Legitimate administrative tasks using tools like curl or socat to interact with Docker for monitoring or management purposes can trigger alerts. To handle this, create exceptions for specific user accounts or scripts that are known to perform these tasks regularly.
- Automated scripts or services that check the status of Docker containers might be flagged. Identify these scripts and whitelist their process names or command lines to prevent unnecessary alerts.
- Development environments where developers frequently use command-line tools to interact with Docker may cause false positives. Consider excluding specific development machines or user groups from the rule to reduce noise.
- Continuous integration or deployment pipelines that use Docker commands as part of their workflow can be mistaken for enumeration attempts. Exclude these processes by identifying their unique command patterns or execution contexts.
- Security tools that perform regular audits or checks on Docker environments might trigger the rule. Verify these tools and add them to an exception list to avoid false alerts.

### Response and remediation

- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
- Terminate any suspicious processes identified in the alert that are interacting with the Docker socket, such as those using curl, socat, or netcat.
- Conduct a thorough review of Docker containers on the affected host to identify any unauthorized or malicious containers. Stop and remove any that are not recognized or are deemed suspicious.
- Check for any unauthorized changes to Docker configurations or images and revert them to a known good state.
- Review and restrict permissions on the Docker socket file (/var/run/docker.sock) to limit access to only trusted users and processes.
- Escalate the incident to the security operations team for further investigation and to determine if additional hosts or systems are affected.
- Implement enhanced monitoring and logging for Docker socket interactions to detect and respond to similar threats more quickly in the future.
"""
risk_score = 47
rule_id = "dd983e79-22e8-44d1-9173-d57dba514cac"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

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

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

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "Domain: Container",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Data Source: Elastic Defend",
    "Data Source: Elastic Endgame",
    "Data Source: Auditd Manager",
    "Data Source: Crowdstrike",
    "Data Source: SentinelOne",
    "Data Source: Elastic Defend for Containers",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
process.name in ("curl", "socat", "nc", "netcat", "ncat", "nc.traditional") and
process.args like ("*/var/run/docker.sock*", "*/run/docker.sock*") and
process.parent.executable != null and
not (
  process.parent.executable in ("/usr/sbin/sshd", "/www/server/panel/BT-Panel") or
  process.parent.args in ("/usr/libexec/netdata/plugins.d/cgroup-name.sh", "/docker-entrypoint")
)
'''

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

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

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

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

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

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

[metadata]
creation_date = "2020/11/17"
integration = ["google_workspace"]
maturity = "production"
updated_date = "2026/06/02"

[rule]
author = ["Elastic"]
description = """
Detects when an administrator adds a domain to the Google Workspace allowlisted (trusted) domains list. Adversaries with
administrative access may onboard a domain they control to relax cross-organization sharing restrictions, enabling
data collection and exfiltration through Drive, Chat, and other services that honor the tenant trust boundary.
"""
false_positives = [
    """
    Trusted domains may be added by system administrators. Verify that the configuration change was expected. Exceptions
    can be added to this rule to filter expected behavior.
    """,
]
from = "now-130m"
index = ["filebeat-*", "logs-google_workspace.admin-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "Domain Added to Google Workspace Trusted Domains"
note = """## Triage and analysis

### Investigating Domain Added to Google Workspace Trusted Domains

Google Workspace allowlisted domains define which external organizations users may collaborate with across services such
as Drive, Chat, and Classroom. Adding a domain to this list expands who can receive shared content under the tenant's
trust policies. Threat actors with administrative access may add a domain they operate to bypass out-of-domain sharing
controls and establish a durable path for collection or exfiltration.

This rule identifies when an administrator adds a domain via the `ADD_TRUSTED_DOMAINS` event in the
`google_workspace.admin` data stream.

### Possible investigation steps

- Identify the initiating (actor) administrator by reviewing `user.email` or `user.name`, and note `source.ip` and `event.ingested` if present in the alert.
- Identify the domain added by reviewing `google_workspace.admin.domain.name`.
- Determine whether the change is expected and authorized:
  - Validate there is an approved change request or partner onboarding record for the new domain.
  - If the actor account or `source.ip` is unusual, treat the alert as higher priority until proven benign.
- Review allowlisted domains in the Google Admin console:
  - Navigate to Account > Domains > Allowlisted domains.
  - Confirm the domain from `google_workspace.admin.domain.name` appears on the list and whether it is appropriate for your organization's sharing model.
- Assess domain reputation and ownership using external intelligence (for example, VirusTotal or WHOIS) to determine whether the domain is associated with your organization or a known partner.
- Search Kibana for related admin and sharing activity:
  - Find other trust or sharing policy changes by the same actor:
    ```
    data_stream.dataset: "google_workspace.admin" and user.email: "<ACTOR_EMAIL>" and event.action: ("ADD_TRUSTED_DOMAINS" or "REMOVE_TRUSTED_DOMAINS")
    ```
  - After the add, review Drive events for files shared to users outside your domain:
    ```
    data_stream.dataset: "google_workspace.drive" and event.action: ("change_user_access" or "change_document_visibility")
    ```
  - Scope for other security-weakening admin actions from the same `user.email` within the last 48 hours.

### False positive analysis

- Verify the domain belongs to an approved partner or subsidiary with a documented business need for cross-organization collaboration.
- Adding test or lab domains during migrations is possible — validate timing against change windows.

### Response and remediation

- Initiate the incident response process based on triage findings.
- If the add is not clearly authorized, remove the domain from Allowlisted domains while the investigation proceeds.
- If the initiating admin account is suspected compromised, reset credentials, revoke active sessions, and review delegated admin roles assigned to that account.
- Review recent Drive and Chat sharing to external users for sensitive data exposure tied to the newly trusted domain.
- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
    - Identify the account role in the cloud environment.
    - Assess the criticality of affected services and servers.
    - Work with your IT team to identify and minimize the impact on users.
    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
    - Identify any regulatory or legal ramifications related to this activity.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
- Review the permissions assigned to the implicated administrator to ensure that the least privilege principle is being followed.
- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google.
- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).

## Setup

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

### Important Information Regarding Google Workspace Event Lag Times
- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs.
- This rule is configured to run every 10 minutes with a lookback time of 130 minutes.
- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events.
- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m).
- See the following references for further information:
  - https://support.google.com/a/answer/7061566
  - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html"""
references = [
    "https://support.google.com/a/answer/6160020?hl=en",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two"
]
risk_score = 73
rule_id = "cf549724-c577-4fd6-8f9b-d1b8ec519ec0"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: Google Workspace",
    "Use Case: Configuration Audit",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:google_workspace.admin and event.action:ADD_TRUSTED_DOMAINS
'''

[rule.investigation_fields]
field_names = [
    "user.name",
    "user.email",
    "source.ip",
    "user.domain",
    "event.action",
    "google_workspace.admin.domain.name",
]

[[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.subtechnique]]
id = "T1484.002"
name = "Trust Modification"
reference = "https://attack.mitre.org/techniques/T1484/002/"

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

[rule]
description = """
Identifies attempt to load an untrusted executable dropped by a Kernel mode code. Adversaries may execute malicious code
in user mode via existing malicious Kernel drivers.
"""
id = "1c618d05-2cac-4979-9c85-6320fc317177"
license = "Elastic License v2"
name = "Execution of a File Dropped from Kernel Mode"
os_list = ["windows"]
version = "1.0.5"

query = '''
sequence with maxspan=5m
  [file where event.action == "creation" and
   /* library dropped via System Virtual Process - Kernel mode code */
   process.pid == 4 and user.id : "S-1-5-18" and
   (file.extension : ("exe", "dll") or file.Ext.header_bytes : "4d5a*")] by file.path 
   [library where process.pid != 4 and not dll.code_signature.status : "trusted" and process.executable != null and
    not dll.hash.sha256 : "6957be7503737453c3feab129d4924fca55e7b0c026ec878d0d040765002732c"] by dll.path
'''

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

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

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


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

[internal]
min_endpoint_version = "8.4.0"

[metadata]
creation_date = "2023/06/26"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
Identifies an attempt to load a revoked or expired driver. Adversaries may bring outdated drivers with vulnerabilities
to gain code execution in kernel mode or abuse revoked certificates to sign their drivers.
"""
from = "now-9m"
index = ["logs-endpoint.events.library-*"]
language = "eql"
license = "Elastic License v2"
name = "Expired or Revoked Driver Loaded"
references = [
    "https://docs.microsoft.com/en-us/previous-versions/windows/hardware/design/dn653559(v=vs.85)?redirectedfrom=MSDN",
]
risk_score = 47
rule_id = "d12bac54-ab2a-4159-933f-d7bcefa7b61d"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
driver where host.os.type == "windows" and process.pid == 4 and
  dll.code_signature.status : ("errorExpired", "errorRevoked")
'''

setup = """## Setup

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

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

note = """## Triage and analysis

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

### Investigating Expired or Revoked Driver Loaded
In Windows environments, drivers facilitate communication between the OS and hardware. Adversaries exploit vulnerabilities in outdated drivers or misuse revoked certificates to execute malicious code in kernel mode, bypassing security controls. The detection rule identifies such threats by monitoring for drivers with expired or revoked signatures, focusing on processes critical to system integrity, thus flagging potential privilege escalation or defense evasion attempts.

### Possible investigation steps

- Review the alert details to confirm the presence of a driver with an expired or revoked signature, focusing on the process with PID 4, which is typically the System process in Windows.
- Investigate the specific driver file that triggered the alert by checking its file path, hash, and any associated metadata to determine its origin and legitimacy.
- Cross-reference the driver file against known vulnerability databases and security advisories to identify any known exploits associated with it.
- Examine recent system logs and security events for any unusual activities or attempts to load other drivers around the same time as the alert.
- Assess the system for any signs of privilege escalation or defense evasion, such as unauthorized access attempts or changes to security settings.
- If the driver is confirmed to be malicious or suspicious, isolate the affected system to prevent further compromise and initiate a detailed forensic analysis.

### False positive analysis

- Legitimate software updates may load drivers with expired or revoked signatures temporarily. Verify the source and purpose of the driver before excluding it.
- Some older hardware devices may rely on drivers that have expired signatures but are still necessary for functionality. Confirm the device's necessity and consider excluding these drivers if they are from a trusted source.
- Security software or system management tools might use drivers with expired signatures for legitimate operations. Validate the software's legitimacy and add exceptions for these drivers if they are verified as safe.
- Custom or in-house developed drivers might not have updated signatures. Ensure these drivers are from a trusted internal source and consider excluding them if they are essential for operations.
- Test environments may intentionally use expired or revoked drivers for research or development purposes. Clearly document these cases and exclude them to prevent unnecessary alerts.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
- Terminate any processes associated with the expired or revoked driver to halt any ongoing malicious activity.
- Conduct a thorough review of the system to identify any unauthorized changes or additional malicious drivers that may have been loaded.
- Revoke any compromised certificates and update the certificate trust list to prevent future misuse.
- Apply the latest security patches and driver updates to close any vulnerabilities that may have been exploited.
- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected.
- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems are affected."""


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

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

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1036.001"
name = "Invalid Code Signature"
reference = "https://attack.mitre.org/techniques/T1036/001/"

[[rule.threat.technique]]
id = "T1553"
name = "Subvert Trust Controls"
reference = "https://attack.mitre.org/techniques/T1553/"

[[rule.threat.technique.subtechnique]]
id = "T1553.002"
name = "Code Signing"
reference = "https://attack.mitre.org/techniques/T1553/002/"

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

[metadata]
creation_date = "2025/06/27"
integration = ["kubernetes"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
This rule detects the deletion of Kubernetes events, which can indicate an attempt to cover up malicious
activity or misconfigurations. Adversaries may delete events to remove traces of their actions, making it
harder for defenders to investigate and respond to incidents.
"""
index = ["logs-kubernetes.audit_logs-*"]
language = "eql"
license = "Elastic License v2"
name = "Kubernetes Events 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 Kubernetes Events Deleted
Kubernetes, a container orchestration platform, logs events to track activities within the cluster. These events are crucial for monitoring and troubleshooting. Adversaries may delete these logs to hide their tracks, impeding incident response. The detection rule identifies deletions of Kubernetes events, signaling potential defense evasion attempts by matching specific audit log attributes, thus alerting security teams to investigate further.

### Possible investigation steps

- Review the audit logs to identify the source of the deletion request by examining the `kubernetes.audit.user.username` field to determine which user or service account initiated the delete action.
- Check the `kubernetes.audit.sourceIPs` field to trace the IP address from which the deletion request originated, which can help identify potential unauthorized access.
- Investigate the `kubernetes.audit.objectRef.namespace` field to understand which namespace the deleted events belonged to, as this can provide context on the affected applications or services.
- Analyze the timeline of events leading up to the deletion by reviewing other audit logs with similar `kubernetes.audit.verb` values to identify any suspicious activities or patterns.
- Assess the role and permissions of the user or service account involved in the deletion to determine if they had legitimate access or if there was a potential privilege escalation.
- Cross-reference the deletion event with other security alerts or logs to identify any correlated activities that might indicate a broader attack or misconfiguration.

### False positive analysis

- Routine maintenance activities may involve the deletion of Kubernetes events, such as during cluster upgrades or cleanup tasks. To manage this, create exceptions for known maintenance periods or specific user accounts responsible for these tasks.
- Automated scripts or tools that manage Kubernetes resources might delete events as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by whitelisting their service accounts or IP addresses.
- Misconfigured applications or services might inadvertently delete events. Regularly review and update configurations to ensure they align with best practices, and consider excluding specific applications if they are known to cause benign deletions.
- Development and testing environments often have more frequent event deletions as part of iterative testing processes. Implement separate monitoring rules or thresholds for these environments to reduce noise in alerts.

### Response and remediation

- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or tampering with event logs.
- Review and restore any deleted Kubernetes events from backup logs or snapshots to ensure a complete audit trail is available for further investigation.
- Conduct a thorough review of access controls and permissions within the Kubernetes environment to identify and revoke any unauthorized access that may have led to the deletion of events.
- Implement stricter logging and monitoring policies to ensure that any future deletions of Kubernetes events are detected and alerted in real-time.
- Escalate the incident to the security operations center (SOC) for a comprehensive analysis of potential breaches and to determine if additional systems or data were affected.
- Coordinate with the incident response team to conduct a root cause analysis and identify any vulnerabilities or misconfigurations that allowed the event deletion to occur.
- Update and reinforce security policies and procedures to prevent similar incidents, including enhancing detection capabilities for defense evasion tactics as outlined in MITRE ATT&CK.
"""
risk_score = 21
rule_id = "33c27b4e-8ec6-406f-b8e5-345dc024aa97"
severity = "low"
tags = [
    "Data Source: Kubernetes",
    "Domain: Kubernetes",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
    ]
timestamp_override = "event.ingested"
type = "eql"
query = '''
any where data_stream.dataset == "kubernetes.audit_logs" and kubernetes.audit.verb == "delete" and
kubernetes.audit.objectRef.resource == "events" and kubernetes.audit.stage == "ResponseComplete"
'''

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

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

[[rule.threat.technique.subtechnique]]
id = "T1070.004"
name = "File Deletion"
reference = "https://attack.mitre.org/techniques/T1070/004/"

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

[metadata]
creation_date = "2020/12/07"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/09/04"

[rule]
author = ["Elastic"]
description = """
An adversary can establish persistence by installing a new launch agent that executes at login by using launchd or
launchctl to load a plist into the appropriate directories.
"""
false_positives = ["Trusted applications persisting via LaunchAgent"]
from = "now-9m"
index = ["logs-endpoint.events.file*", "logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Launch Service Creation and Immediate Loading"
references = [
    "https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html",
]
risk_score = 21
rule_id = "082e3f8c-6f80-485c-91eb-5b112cb79b28"
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 = "low"
tags = [
    "Domain: Endpoint",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
type = "eql"

query = '''
sequence by host.id with maxspan=30s
 [file where host.os.type == "macos" and event.action == "launch_daemon"] by process.entity_id
 [process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "launchctl" and process.args in ("load", "bootstrap")] by process.parent.entity_id
'''
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 Launch Service Creation and Immediate Loading

Launch Agents in macOS are used to execute scripts or applications automatically at user login, providing a mechanism for persistence. Adversaries exploit this by creating or modifying Launch Agents to execute malicious payloads. The detection rule identifies such activities by monitoring file changes in Launch Agent directories and subsequent immediate loading via `launchctl`, indicating potential unauthorized persistence attempts.

### Possible investigation steps

- Review the file path where the modification or creation of the Launch Agent occurred to determine if it is in a system directory (e.g., /System/Library/LaunchAgents/) or a user directory (e.g., /Users/*/Library/LaunchAgents/). This can help assess the potential impact and scope of the change.
- Examine the contents of the newly created or modified plist file to identify the script or application it is configured to execute. Look for any suspicious or unexpected entries that could indicate malicious activity.
- Check the timestamp of the file modification event to correlate it with any known user activities or other system events that might explain the change.
- Investigate the process execution details of the launchctl command, including the user account under which it was executed and any associated parent processes, to determine if it aligns with legitimate administrative actions or if it appears suspicious.
- Search for any additional related alerts or logs around the same timeframe that might indicate further malicious behavior or corroborate the persistence attempt, such as other process executions or network connections initiated by the suspicious process.

### False positive analysis

- System or application updates may create or modify Launch Agents as part of their installation or update process. Users can create exceptions for known and trusted applications by whitelisting their specific file paths or process names.
- User-installed applications that require background processes might use Launch Agents for legitimate purposes. Identify these applications and exclude their associated Launch Agent paths from monitoring.
- Administrative scripts or tools used by IT departments for system management might trigger this rule. Coordinate with IT to document these scripts and exclude their activities from detection.
- Development tools or environments that automatically configure Launch Agents for testing purposes can cause false positives. Developers should be aware of these activities and can exclude their specific development directories.
- Backup or synchronization software that uses Launch Agents to schedule tasks may be flagged. Verify these applications and exclude their Launch Agent paths if they are deemed safe.

### Response and remediation

- Immediately isolate the affected macOS system from the network to prevent further malicious activity or lateral movement.
- Terminate any suspicious processes associated with the unauthorized Launch Agent using Activity Monitor or the `kill` command in Terminal.
- Remove the malicious Launch Agent plist file from the affected directories: `/System/Library/LaunchAgents/`, `/Library/LaunchAgents/`, or `/Users/*/Library/LaunchAgents/`.
- Review and restore any system or application settings that may have been altered by the malicious Launch Agent.
- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes.
- Monitor the system for any signs of re-infection or further unauthorized changes to Launch Agents, ensuring that logging and alerting are configured to detect similar activities.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""


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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1543.004"
name = "Launch Daemon"
reference = "https://attack.mitre.org/techniques/T1543/004/"

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

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

[[rule.threat.technique]]
id = "T1569"
name = "System Services"
reference = "https://attack.mitre.org/techniques/T1569/"

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

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

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

[rule]
author = ["Elastic"]
description = """
Identifies when a Safe Link policy is disabled in Microsoft 365. Safe Link policies for Office applications extend
phishing protection to documents that contain hyperlinks, even after they have been delivered to a user.
"""
false_positives = [
    """
    Disabling safe links may be done 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 Email Safe Link Policy 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 M365 Exchange Email Safe Link Policy Disabled

Microsoft 365's Safe Link policies enhance security by scanning hyperlinks in documents for phishing threats, even post-delivery. Disabling these policies can expose users to phishing attacks. Adversaries might exploit this by disabling Safe Links to facilitate malicious link delivery. The detection rule identifies successful attempts to disable Safe Link policies, signaling potential security breaches.

### Possible investigation steps

- Review the event logs for the specific event.dataset:o365.audit and event.provider:Exchange to confirm the occurrence of the "Disable-SafeLinksRule" action with a successful outcome.
- Identify the user account associated with the event.action:"Disable-SafeLinksRule" to determine if the action was performed by an authorized individual or if the account may have been compromised.
- Check the recent activity of the identified user account for any unusual or unauthorized actions that could indicate a broader security incident.
- Investigate any recent changes to Safe Link policies in the Microsoft 365 environment to understand the scope and impact of the policy being disabled.
- Assess whether there have been any recent phishing attempts or suspicious emails delivered to users, which could exploit the disabled Safe Link policy.
- Coordinate with the IT security team to re-enable the Safe Link policy and implement additional monitoring to prevent future unauthorized changes.

### False positive analysis

- Administrative changes: Legitimate administrative actions may involve disabling Safe Link policies temporarily for testing or configuration purposes. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
- Third-party integrations: Some third-party security tools or integrations might require Safe Link policies to be disabled for compatibility reasons. Identify and document these tools, and set up exceptions for their associated actions.
- Policy updates: During policy updates or migrations, Safe Link policies might be disabled as part of the process. Monitor and document these events, and exclude them from alerts if they match known update patterns.
- User training sessions: Safe Link policies might be disabled during user training or demonstrations to showcase potential threats. Schedule these sessions and exclude related activities from triggering alerts.

### Response and remediation

- Immediately re-enable the Safe Link policy in Microsoft 365 to restore phishing protection for hyperlinks in documents.
- Conduct a thorough review of recent email and document deliveries to identify any potentially malicious links that may have been delivered while the Safe Link policy was disabled.
- Isolate any identified malicious links or documents and notify affected users to prevent interaction with these threats.
- Investigate the account or process that disabled the Safe Link policy to determine if it was compromised or misused, and take appropriate actions such as password resets or privilege revocation.
- Escalate the incident to the security operations team for further analysis and to determine if additional security measures are needed to prevent similar incidents.
- Implement additional monitoring and alerting for changes to Safe Link policies to ensure rapid detection of any future unauthorized modifications.
- Review and update access controls and permissions related to Safe Link policy management to ensure only authorized personnel can make changes.

## 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/disable-safelinksrule?view=exchange-ps",
    "https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/atp-safe-links?view=o365-worldwide",
]
risk_score = 47
rule_id = "a989fa1b-9a11-4dd8-a3e9-f0de9c6eb5f2"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: Microsoft 365",
    "Use Case: Identity and Access 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:"Disable-SafeLinksRule" 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 = "2023/08/23"
integration = ["endpoint", "m365_defender", "system", "crowdstrike"]
maturity = "production"
updated_date = "2026/07/28"

[rule]
author = ["Elastic"]
description = """
Managed Object Format (MOF) files can be compiled locally or remotely through mofcomp.exe. Attackers may leverage MOF
files to build their own namespaces and classes into the Windows Management Instrumentation (WMI) repository, or
establish persistence using WMI Event Subscription.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process-*",
    "logs-m365_defender.event-*",
    "logs-system.security*",
]
language = "eql"
license = "Elastic License v2"
name = "Mofcomp Activity"
risk_score = 21
rule_id = "210d4430-b371-470e-b879-80b7182aa75e"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Data Source: Elastic Defend",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Elastic Endgame",
    "Data Source: Windows Security Event Logs",
    "Data Source: Crowdstrike",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and
  process.name : "mofcomp.exe" and process.args : "*.mof" and
  not user.id : "S-1-5-18" and
  not process.args : (
    "?:\\Program Files (x86)\\Microsoft Power BI Report Server\\*.mof",
    "?:\\Program Files (x86)\\Microsoft SQL Server Reporting Services\\*.mof",
    "?:\\Program Files (x86)\\Microsoft SQL Server\\*.mof",
    "?:\\Program Files\\Microsoft Policy Platform\\*.mof",
    "?:\\Program Files\\Microsoft Power BI Report Server\\*.mof",
    "?:\\Program Files\\Microsoft SQL Server Reporting Services\\*.mof",
    "?:\\Program Files\\Microsoft SQL Server\\*.mof",
    "?:\\Windows\\System32\\wbem\\com.hp.provider.*.mof",
    "?:\\Windows\\System32\\wbem\\CxAudioSvc_*.mof",
    "?:\\Windows\\System32\\wbem\\Framework\\root\\*.mof",
    "?:\\Windows\\System32\\wbem\\Veeam.Backup.*.mof",
    "?:\\Windows\\System32\\wbem\\ZTITatoo.mof",
    "?:\\Windows\\SysWOW64\\wbem\\Framework\\root\\*.mof"
  )
'''

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)
- [Windows Process Creation Logs](https://ela.st/audit-process-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 Mofcomp Activity
Mofcomp.exe is a tool used to compile Managed Object Format (MOF) files, which define classes and namespaces in the Windows Management Instrumentation (WMI) repository. Adversaries exploit this by creating malicious WMI scripts for persistence or execution. The detection rule identifies suspicious mofcomp.exe activity by filtering out legitimate processes and focusing on unusual executions, excluding known safe parent processes and system accounts.

### Possible investigation steps

- Review the process execution details to confirm the presence of mofcomp.exe and verify the command-line arguments used, focusing on any unusual or unexpected MOF file paths.
- Investigate the user account associated with the process execution, especially if it is not the system account (S-1-5-18), to determine if the account has been compromised or is being misused.
- Examine the parent process of mofcomp.exe to ensure it is not a known safe process like ScenarioEngine.exe, and assess whether the parent process is legitimate or potentially malicious.
- Check for any recent changes or additions to the WMI repository, including new namespaces or classes, which could indicate malicious activity or persistence mechanisms.
- Correlate the alert with other security events or logs from data sources like Microsoft Defender XDR or Crowdstrike to identify any related suspicious activities or patterns.

### False positive analysis

- Legitimate SQL Server operations may trigger the rule when SQL Server components compile MOF files. To handle this, exclude processes with parent names like ScenarioEngine.exe and specific MOF file paths related to SQL Server.
- System maintenance tasks executed by trusted system accounts can cause false positives. Exclude activities initiated by the system account with user ID S-1-5-18 to reduce noise.
- Regular administrative tasks involving WMI may appear suspicious. Identify and document these tasks, then create exceptions for known safe parent processes or specific MOF file paths to prevent unnecessary alerts.
- Software installations or updates that involve MOF file compilation might be flagged. Monitor installation logs and exclude these processes if they are verified as part of legitimate software updates.

### Response and remediation

- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
- Terminate the mofcomp.exe process if it is confirmed to be executing malicious MOF files.
- Conduct a thorough review of the WMI repository to identify and remove any unauthorized namespaces or classes that may have been created by the attacker.
- Remove any malicious MOF files from the system to prevent re-execution.
- Restore the system from a known good backup if unauthorized changes to the WMI repository or system files are detected.
- Monitor for any recurrence of similar activity by setting up alerts for unusual mofcomp.exe executions and unauthorized WMI modifications.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1047"
name = "Windows Management Instrumentation"
reference = "https://attack.mitre.org/techniques/T1047/"


[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1546"
name = "Event Triggered Execution"
reference = "https://attack.mitre.org/techniques/T1546/"
[[rule.threat.technique.subtechnique]]
id = "T1546.003"
name = "Windows Management Instrumentation Event Subscription"
reference = "https://attack.mitre.org/techniques/T1546/003/"



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

[metadata]
creation_date = "2024/03/13"
integration = ["auditd_manager", "endpoint"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
Monitors for the execution of a unix binary with read, write and execute memory region permissions, followed by a
network connection. The mprotect() system call is used to change the access protections on a region of memory that has
already been allocated. This syscall allows a process to modify the permissions of pages in its virtual address space,
enabling or disabling permissions such as read, write, and execute for those pages. RWX permissions on memory is in many
cases overly permissive, and should (especially in conjunction with an outbound network connection) be analyzed
thoroughly.
"""
from = "now-9m"
index = ["auditbeat-*", "logs-auditd_manager.auditd-*", "logs-endpoint.events.network*", "logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Network Connection from Binary with RWX Memory Region"
references = [
    "https://man7.org/linux/man-pages/man2/mprotect.2.html",
    "https://www.elastic.co/security-labs/linux-detection-engineering-with-auditd",
]
risk_score = 47
rule_id = "32300431-c2d5-432d-8ec8-0e03f9924756"
setup = """## Setup

This rule requires the use of the `auditd_manager` integration. `Auditd_manager` is a tool designed to simplify and enhance the management of the audit subsystem in Linux systems. It provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. The following steps should be executed in order to install and deploy `auditd_manager` on a Linux system.
```
Kibana -->
Management -->
Integrations -->
Auditd Manager -->
Add Auditd Manager
```
`Auditd_manager` subscribes to the kernel and receives events as they occur without any additional configuration. However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from.
For this detection rule to trigger, the following additional audit rules are required to be added to the integration:
```
-a always,exit -F arch=b64 -S mprotect
```
Add the newly installed `auditd manager` to an agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Data Source: Elastic Defend",
    "Data Source: Auditd Manager",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
sample by host.id, process.pid, process.name
  /* auditd.data.a2 == "7" translates to RWX memory region protection (PROT_READ | PROT_WRITE | PROT_EXEC) */
  [process where host.os.type == "linux" and auditd.data.syscall == "mprotect" and auditd.data.a2 == "7" and
   not process.name in ("httpd", "java", "node", "code", "apache2")]
  [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and
   not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")]
'''
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 from Binary with RWX Memory Region

In Linux environments, the `mprotect()` system call adjusts memory permissions, potentially enabling read, write, and execute (RWX) access. Adversaries exploit this to execute malicious code in memory, often followed by network connections to exfiltrate data or communicate with command-and-control servers. The detection rule identifies such behavior by monitoring for RWX memory changes and subsequent network activity, flagging suspicious processes for further analysis.

### Possible investigation steps

- Review the process details using the process.pid and process.name fields to identify the binary that requested RWX memory permissions.
- Investigate the context of the mprotect() syscall by examining the process's command line arguments and parent process to understand its origin and purpose.
- Analyze the network connection details, focusing on the destination.ip field, to determine if the connection was made to a known malicious IP or an unusual external server.
- Check the process's execution history and any associated files or scripts to identify potential malicious payloads or scripts that may have been executed.
- Correlate the event with other security logs or alerts from the same host.id to identify any related suspicious activities or patterns.
- Assess the risk and impact by determining if any sensitive data was accessed or exfiltrated during the network connection attempt.

### False positive analysis

- Legitimate software updates or patches may temporarily use RWX memory regions. Monitor the specific process names and verify if they are associated with known update mechanisms. Consider adding these processes to an exception list if they are verified as safe.
- Development tools and environments often require RWX permissions for debugging or testing purposes. Identify these tools and exclude them from the rule if they are part of a controlled and secure development environment.
- Certain system services or daemons, like custom web servers or network services, might use RWX memory regions for legitimate reasons. Review the process names and network destinations to determine if they are part of expected system behavior, and exclude them if confirmed.
- Security software or monitoring tools may exhibit this behavior as part of their normal operation. Validate these processes and consider excluding them if they are recognized as part of your security infrastructure.
- Custom scripts or automation tasks that require dynamic code execution might trigger this rule. Ensure these scripts are reviewed and approved, then exclude them if they are deemed non-threatening.

### Response and remediation

- Isolate the affected host from the network immediately to prevent further data exfiltration or communication with potential command-and-control servers.
- Terminate the suspicious process identified by the detection rule to halt any ongoing malicious activity.
- Conduct a memory dump of the affected system to capture the current state for forensic analysis, focusing on the RWX memory regions.
- Review and analyze the network logs to identify any external IP addresses or domains the process attempted to connect to, and block these on the network firewall.
- Patch and update the affected system to the latest security updates to mitigate any known vulnerabilities that could have been exploited.
- Implement stricter memory protection policies to prevent processes from obtaining RWX permissions unless absolutely necessary.
- Escalate the incident to the security operations center (SOC) for further investigation and to determine if this is part of a larger attack campaign."""

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

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

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

[[rule.threat.technique]]
id = "T1106"
name = "Native API"
reference = "https://attack.mitre.org/techniques/T1106/"

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

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

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

[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 = "T1620"
name = "Reflective Code Loading"
reference = "https://attack.mitre.org/techniques/T1620/"

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

[rule]
description = """
Identifies the execution of an unsigned program or script from the Startup shell folder followed by an immediate network
connection. This may indicate the presence of a malicious persistent item.
"""
id = "0b33141a-3f73-4414-ba90-d8410e6ab176"
license = "Elastic License v2"
name = "Network Connection via Startup Item"
os_list = ["windows"]
version = "1.0.31"

query = '''
sequence by process.entity_id with maxspan=1m
 [process where event.action == "start" and
  (
   // unsigned program starting from startup folder
   (process.executable : (
    "?:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*",
    "?:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*")  and
    not process.code_signature.trusted == true) or

    // Scripts starting from startup folder
   (process.name : ("cscript.exe", "wscript.exe", "mshta.exe", "powershell.exe") and
    process.command_line : (
        "*:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*",
        "*:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*"))
  ) and

  /* ConnectWiseManage - unsigned */
  not process.hash.sha256 : "cac904da410372bcd0797b4bfa402c8f8663040f26e80a435d98d12bd2fa6659"]
 [network where not cidrmatch(destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24",
       "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32",
       "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", "192.88.99.0/24", "224.0.0.0/4",
       "100.64.0.0/10", "192.168.0.0/16", "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1",
       "FE80::/10", "FF00::/8")]
'''

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

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

[[threat.technique.subtechnique]]
id = "T1059.005"
name = "Visual Basic"
reference = "https://attack.mitre.org/techniques/T1059/005/"

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



[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1547"
name = "Boot or Logon Autostart Execution"
reference = "https://attack.mitre.org/techniques/T1547/"
[[threat.technique.subtechnique]]
id = "T1547.001"
name = "Registry Run Keys / Startup Folder"
reference = "https://attack.mitre.org/techniques/T1547/001/"



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



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

[internal]
min_endpoint_version = "7.15.0"

[rule]
description = """
This rule detects a network connection attempt to an external IP address followed by a file deletion event where the
file path is the same as the process executable. This behavior may indicate an attempt to cover tracks by deleting the
file used to establish the connection, and may be used by attackers to hide their tracks upon successfully establishing
a connection to a C2 server.
"""
id = "e64787a1-801e-48d2-a09e-d474bba68197"
license = "Elastic License v2"
name = "Outbound Network Connection Followed by Process File Deletion"
os_list = ["linux"]
version = "1.0.7"

query = '''
sequence by process.parent.entity_id with maxspan=10s
  [network where event.type == "start" and event.action == "connection_attempted" and
   process.executable like ("/tmp/*", "/var/tmp/*", "/dev/shm/*") 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"
     ) or
     process.executable like (
       "/tmp/regctl", "/tmp/token_handler", "/tmp/tmp.*/juliainstaller", "/tmp/tmp.*/rustup-init",
       "/tmp/tmp.*/elan-init", "/var/tmp/tmp.*/rustup-init", "/tmp/SophosCentralInstall*/bin/telemetry",
       "/tmp/bdconfigure.*/bdconfigure64", "/tmp/nanolayer*/nanolayer", "/tmp/tmp.*/pgp-file-protect",
       "/tmp/tmp.*/rover", "/tmp/tmp.*/sq-ccm", "/tmp/trizen-fric/jfrog-cli/src/jfrog-cli-*/jf",
       "/var/tmp/sdcss_Uninstalltelemetry/seticli", "/tmp/tmp.*/goreleaser", "/var/tmp/tmp.*/hab-x86_64-linux/hab",
       "/tmp/buildroot-*/python/bin/python*", "/tmp/confluent"
     )
   )] as event0
  [file where event.type == "deletion" and process.name == "rm" and startswith~(file.path, event0.process.executable)]
'''

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

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

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

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

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



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


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

[internal]
min_endpoint_version = "8.6.0"

[metadata]
creation_date = "2020/03/25"
integration = ["endpoint", "windows"]
maturity = "production"
updated_date = "2026/04/22"

[rule]
author = ["Elastic"]
description = """
An instance of MSBuild, the Microsoft Build Engine, loaded DLLs (dynamically linked libraries) responsible for Windows
credential management. This technique is sometimes used for credential dumping.
"""
false_positives = ["The Build Engine is commonly used by Windows developers but use by non-engineers is unusual."]
from = "now-9m"
index = [
    "winlogbeat-*",
    "logs-endpoint.events.process-*",
    "logs-endpoint.events.library-*",
    "logs-windows.sysmon_operational-*",
]
language = "eql"
license = "Elastic License v2"
name = "Potential Credential Access via Trusted Developer Utility"
references = [
    "https://lolbas-project.github.io/lolbas/Binaries/Msbuild/",
]
risk_score = 73
rule_id = "9d110cb3-5f4b-4c9a-b9f5-53f0a1707ae5"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
sequence by process.entity_id
 [process where host.os.type == "windows" and event.type == "start" and (process.name : "MSBuild.exe" or process.pe.original_file_name == "MSBuild.exe")]
 [library where host.os.type == "windows" and dll.name : ("vaultcli.dll", "SAMLib.DLL")]
'''

note = """## Triage and analysis

### Investigating Potential Credential Access via Trusted Developer Utility

#### Possible investigation steps

- What do the matched source events show about the MSBuild instance?
  - Focus: Timeline source events for `process.entity_id` -- the start-event `process.executable` and `process.command_line` plus the library-stage `dll.path`.
  - Implication: more concerning when MSBuild loads vaultcli.dll or SAMLib.dll from an unusual path or unexpected context; more explainable when Timeline shows a recognized build task loading the library from the default Windows system directory.

- Is the MSBuild binary and launch chain expected for this host?
  - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.parent.executable`.
  - Implication: more concerning when MSBuild is renamed, unsigned, user-writable, outside expected .NET Framework or Visual Studio build roots, or launched by Office, a script host, an archive utility, or another unexpected parent.

- Does the command line or project path suggest transient or user-delivered build content?
  - Focus: `process.command_line` and `process.working_directory`, especially .csproj, .xml, .proj, /logger, or @ response-file paths in temp folders, downloads, removable media, user-profile paths, or network shares.
  - Implication: supports concern when MSBuild runs user-delivered project content, logger DLLs, response files, or inline tasks outside normal compilation; less suspicious when the project resides in a stable source-tree or CI workspace and the build arguments match a recurring compilation pattern.

- Does the loaded credential library path, trust, and recency fit legitimate development behavior?
  - Focus: `dll.name`, `dll.path`, `dll.code_signature.trusted`, and `dll.Ext.relative_file_creation_time`.
  - Implication: supports concern when vaultcli or SAMLib loads from user-writable or transient paths, arrives unsigned, or was created shortly before the load; weaker support when the path is the expected Windows system directory and project context supports a recognized credential-management test.

- Do file writes or child processes show MSBuild acting as a launcher instead of a compiler?
  - Focus: file activity from `process.entity_id`: written `file.path` values, especially payloads, scripts, or compiled artifacts in user-writable paths. $investigate_2
  - Hint: review child starts where `process.parent.entity_id` equals the MSBuild entity; shell or script-engine children are stronger than normal compiler toolchain children. $investigate_3
  - Implication: suggests proxy execution when MSBuild drops payloads, stages scripts or compiled artifacts, or spawns shells or script engines. Missing file telemetry is unresolved, not benign.

- Do MSBuild or its child processes attempt off-host staging?
  - Focus: same-host connection events for the MSBuild `process.entity_id` or direct children where `process.parent.entity_id` matches the MSBuild entity, with `destination.ip` and `destination.port`. $investigate_4
  - Implication: supports containment when suspicious project, DLL, file, or child-process evidence is followed by outbound staging; missing network telemetry is unresolved, not benign.

- Does the user and host context fit developer or build-runner activity?
  - Focus: `user.id`, `user.domain`, `process.Ext.session_info.logon_type`, `host.id`, and `host.name`; compare prior source events for the same user-host cohort.
  - Implication: risk rises when the user-host pair has no recurring build-tool history or when the session type is unexpected; lower only when the user, host, session, and source events fit a bounded developer or build-service pattern.

- If local MSBuild evidence is still suspicious, does related alert history show the same user or host reusing trusted-utility abuse patterns?
  - Focus: related alerts for `user.id`, especially trusted-utility abuse, credential access, lateral movement, or launches of "InstallUtil", "RegAsm", "MSHTA", or similar signed proxies; inspect their source events before comparing project paths or destinations. $investigate_0
  - Hint: compare `host.id` alert history to assess whether activity is confined to this asset. $investigate_1
  - Implication: suggests broader scope when the same user or host shows trusted-utility abuse, persistence, staging, or credential-access alerts; stays localized when history is limited to the same recognized build or test workflow on this asset.

- Escalate when MSBuild identity, project path, loaded library, follow-on behavior, user-host context, or alert scope show unrecognized use, credential-library loads from non-standard paths, or payload behavior; close only when all jointly fit a recognized build or test scenario; preserve and escalate when evidence is mixed or visibility incomplete.

### False positive analysis

- Authorized credential-management tests, security-tool validation, or build pipelines compiling code that uses Windows credential APIs can legitimately trigger vaultcli.dll or SAMLib.dll loads. Confirm only when `process.command_line`, project path, `dll.path`, `process.executable`, `process.parent.executable`, `user.id`, and `host.id` align with that same recognized lab or build-pipeline workflow. If records are unavailable, require the same process-identity fields, loaded `dll.path`, and `user.id`/`host.id` to recur across prior alerts before treating the activity as benign.
- Before creating an exception, validate that `process.executable`, `process.code_signature.subject_name`, `process.parent.executable`, stable `process.command_line` pattern, loaded `dll.path`, `user.id`, and `host.id` recur across prior alerts from this rule. Build the exception from that minimum confirmed workflow pattern. Avoid exceptions on `process.name` alone, the library name alone, or the host alone.

### Response and remediation

- If confirmed benign, reverse temporary containment and record the confirmed explanation in `process.executable`, `process.parent.executable`, project path from `process.command_line`, loaded `dll.path`, `user.id`, and `host.id`. Create an exception only if that same pattern recurs consistently across prior alerts from this rule.
- If suspicious but unconfirmed, preserve a case export for the recovered MSBuild process, its command line, project/task files, loaded credential DLL, dropped artifacts, child-process lineage, and confirmed destinations. Apply reversible containment first -- temporary destination restrictions or heightened monitoring on `host.id` and `user.id` -- and escalate to host isolation only when preserved evidence shows meaningful staging or payload risk.
- If confirmed malicious, use endpoint response actions to isolate the host and terminate MSBuild or its staging child processes after preserving the recovered MSBuild and parent entity IDs, project files, compiled artifacts, child processes, confirmed destinations, and loaded DLL path. If direct endpoint response is unavailable, hand off that artifact set immediately to the team that can isolate the host or block the destinations.
- Eradicate the malicious project files, inline tasks, payloads, persistence artifacts, and secondary tooling uncovered during the investigation, then remediate the delivery or execution-control gap that allowed MSBuild to proxy the credential-access behavior.
- Investigate credential exposure based on what the project targeted: review Windows Credential Manager, saved secrets, and local-account exposure on the host, and rotate or revoke affected credentials according to the recovered artifacts and follow-on activity.
- Review related hosts for the same project-path pattern, library-load combination, child-process behavior, and adjacent trusted-developer-utility abuse before deleting files or removing tooling, and retain process, library, file, and network telemetry needed for future cases.
"""

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:

- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Sysmon Event ID 7 - Image Loaded](https://ela.st/sysmon-event-7-setup)
"""

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "host.id",
    "user.name",
    "user.id",
    "process.entity_id",
    "process.executable",
    "process.command_line",
    "process.working_directory",
    "process.parent.executable",
    "process.code_signature.subject_name",
    "process.Ext.session_info.logon_type",
    "dll.name",
    "dll.path",
    "dll.code_signature.trusted",
    "dll.Ext.relative_file_creation_time",
]

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

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

[[transform.investigate]]
label = "File activity for the MSBuild process and children"
description = ""
providers = [
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" }
  ],
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

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

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

[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1003"
name = "OS Credential Dumping"
reference = "https://attack.mitre.org/techniques/T1003/"
[[rule.threat.technique.subtechnique]]
id = "T1003.002"
name = "Security Account Manager"
reference = "https://attack.mitre.org/techniques/T1003/002/"

[[rule.threat.technique]]
id = "T1555"
name = "Credentials from Password Stores"
reference = "https://attack.mitre.org/techniques/T1555/"
[[rule.threat.technique.subtechnique]]
id = "T1555.004"
name = "Windows Credential Manager"
reference = "https://attack.mitre.org/techniques/T1555/004/"

[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1127"
name = "Trusted Developer Utilities Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1127/"
[[rule.threat.technique.subtechnique]]
id = "T1127.001"
name = "MSBuild"
reference = "https://attack.mitre.org/techniques/T1127/001/"

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