Elastic rules: 09

[rule]
description = """
Identifies the creation of a .NET COM object in an unexpected Windows script interpreter. Adversaries may utilise .NET
to call arbitrary Win32 APIs from scripts.
"""
id = "1e9ac3fe-edb4-d669-71ab-220acc092982"
license = "Elastic License v2"
name = ".NET COM object created in non-standard Windows Script Interpreter"
os_list = ["windows"]
reference = ["https://github.com/tyranid/DotNetToJScript"]
version = "1.0.11"

query = '''
api where
  not process.name : ("cscript.exe", "wscript.exe") and
  process.code_signature.trusted == true and
  process.code_signature.subject_name like "Microsoft*" and
  process.Ext.api.name == "VirtualAlloc" and
  process.Ext.api.parameters.allocation_type == "RESERVE" and
  process.Ext.api.parameters.protection == "RWX" and
  process.thread.Ext.call_stack_summary like (
    /* .NET is allocating executable memory on behalf of a WSH script engine
     * Note - this covers both .NET 2 and .NET 4 framework variants */
    "*|mscoree.dll|combase.dll|jscript.dll|*",
    "*|mscoree.dll|combase.dll|vbscript.dll|*",
    /* These aren't WSH script engines - but the technique is likely still valid */
    "*|mscoree.dll|combase.dll|jscript9.dll|*",
    "*|mscoree.dll|combase.dll|chakra.dll|*"
) and

process.parent.executable != null and

not (process.executable : "?:\\Windows\\SysWOW64\\msiexec.exe" and 
     process.parent.executable : "?:\\Windows\\System32\\msiexec.exe" and 
     process.thread.Ext.call_stack_summary like "*|mscoree.dll|combase.dll|vbscript.dll|*|rpcrt4.dll|*") and

not (process.name : "mshta.exe" and 
     process.parent.executable : ("?:\\Program Files (x86)\\Amazon\\Amazon Assistant\\amazonAssistantService.exe", 
                                  "?:\\Program Files\\Microsoft Configuration Manager\\AdminConsole\\bin\\Microsoft.ConfigurationManagement.exe",
                                  "?:\\Program Files\\Bentley\\*.exe")) and 

not (process.executable : "?:\\Program Files (x86)\\Internet Explorer\\iexplore.exe" and 
     process.parent.executable : "?:\\Program Files\\Internet Explorer\\iexplore.exe" and
     process.thread.Ext.call_stack_summary like "*|combase.dll|jscript9.dll|*") and

/* ASP VBScript (System32 + SysWOW64 w3wp) */
not (process.Ext.api.name == "VirtualAlloc" and 
     process.executable : ("?:\\Windows\\System32\\inetsrv\\w3wp.exe", "?:\\Windows\\SysWOW64\\inetsrv\\w3wp.exe") and
     process.thread.Ext.call_stack_summary like "*|mscoree.dll|combase.dll|vbscript.dll|asp.dll|comsvcs.dll|*") and

/* JumpCloud */
not (process.executable : "?:\\Windows\\System32\\LogonUI.exe" and
     process.thread.Ext.call_stack_summary like "*|vbscript.dll|*" and
     not process.thread.Ext.call_stack_summary like "*Unbacked*") and

not (process.command_line : "\"mshta.exe\" \"C:\\Program Files (x86)\\Amazon\\Amazon Assistant\\aa.hta\"" and
    process.parent.executable : "C:\\Program Files (x86)\\Amazon\\Amazon Assistant\\amazonAssistantService.exe") and

not (process.executable : "?:\\Program Files\\Microsoft SQL Server\\*\\DTS\\Binn\\DTExec.exe" and
     process.parent.executable : "?:\\Program Files\\Microsoft SQL Server\\*\\MSSQL\\Binn\\SQLAGENT.EXE") and

not (process.executable : "C:\\Program Files\\Microsoft Office\\root\\Office??\\OUTLOOK.EXE" and
     process.thread.Ext.call_stack_summary like "*combase.dll|vbscript.dll|mso30win32client.dll*") and
not (process.executable : "C:\\Windows\\System32\\CredentialUIBroker.exe" and
     process.parent.executable : "C:\\Windows\\System32\\svchost.exe" and
     process.thread.Ext.call_stack_summary == "ntdll.dll|kernelbase.dll|clr.dll|mscoreei.dll|mscoree.dll|combase.dll|jscript.dll|kernel32.dll|ntdll.dll") and
not (process.executable : "C:\\Windows\\System32\\SearchFilterHost.exe" and process.parent.executable : "C:\\Windows\\System32\\SearchIndexer.exe" and
     process.thread.Ext.call_stack_summary : "ntdll.dll*|kernelbase.dll|clr.dll|mscoreei.dll|mscoree.dll|combase.dll|*|offfiltx.dll|*|rpcrt4.dll|combase.dll|rpcrt4.dll|ntdll.dll|kernel32.dll|ntdll.dll")
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[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/"

[internal]
min_endpoint_version = "8.8.0"

[metadata]
creation_date = "2026/03/20"
integration = ["auditd_manager"]
maturity = "production"
updated_date = "2026/03/20"

[rule]
author = ["Elastic"]
description = """
Identifies events where the AppArmor security module blocked or restricted an operation due to a policy violation.
AppArmor enforces mandatory access control policies that limit how processes interact with system resources such as
files, network sockets, and capabilities. When a process attempts an action that is not permitted by the active
profile, the kernel generates a policy violation event. While these events can occur during normal operation or
misconfiguration, they may also indicate attempted privilege escalation, restricted file access, or malicious
activity being prevented by the system's security policy.
"""
from = "now-9m"
index = [
    "logs-auditd_manager.auditd-*",
    "auditbeat-*",
]
language = "eql"
license = "Elastic License v2"
name = "AppArmor Policy Violation Detected"
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 AppArmor Policy Violation Detected

This alert shows that AppArmor blocked or limited a Linux process because it tried to act outside its assigned security profile, which can reveal privilege escalation, restricted file access, or defense-evasion activity being stopped by the kernel. An attacker who gains code execution in a web-facing service might try to read `/etc/shadow`, spawn a shell from the confined process, or touch protected sockets, causing this violation when AppArmor contains the behavior.

### Possible investigation steps

- Determine which AppArmor profile produced the denial and what resource or capability was blocked, then judge whether the attempted action matches the application's expected behavior or suggests shell execution, credential access, or unusual network activity.
- Build a short timeline around the event for the affected workload to identify preceding parent-child process chains, interactive sessions, failed access attempts, new persistence artifacts, or outbound connections that indicate exploitation rather than misconfiguration.
- Review recent software deployments, package updates, profile changes, and administrator actions on the host to verify whether the violation began after a legitimate change that may require profile tuning or rollback.
- If the denied behavior is unexpected or repeated, validate the integrity and reputation of the involved binary or script against known-good versions from the environment and inspect its execution context for signs of tampering or abuse.
- For violations that align with malicious behavior, preserve relevant audit and system logs, contain the host or impacted service as needed, remove any confirmed malicious artifacts, and retain or harden the AppArmor policy that successfully blocked the action.

### False positive analysis

- A legitimate application or package update may change binaries, file paths, or socket usage without a matching AppArmor profile update, so verify the alert timing against recent host software changes and confirm the denied path or capability is part of the application's documented normal operation.
- An administrator-initiated maintenance task or service restart can trigger a confined process to access temporary files, logs, or helper executables outside its usual profile, so review the parent process, command line, and user context to confirm it aligns with expected maintenance activity on the host.

### Response and remediation

- Isolate the affected Linux host or container from the network, stop the compromised service or process that triggered the AppArmor denial, and disable any abused user or service account to prevent additional attacker execution.
- Remove attacker footholds by deleting unauthorized systemd units, cron jobs, startup scripts, SSH `authorized_keys` additions, dropped web shells, or replaced binaries linked to the confined process, then terminate any related child shells or reverse-connection tools.
- Restore the workload to a known-good state by rebuilding the host or redeploying the service from a trusted image, reinstalling affected packages, validating critical files such as `/etc/passwd`, `/etc/shadow`, and application binaries against baseline hashes, and rotating any credentials the process may have reached.
- Escalate to incident response immediately if the denial came from an internet-facing service, involved attempts to spawn a shell or read protected files, showed tampering with `/etc/apparmor.d/`, or appeared on multiple hosts, because these are strong indicators of active exploitation or wider compromise.
- Harden the environment by keeping AppArmor in enforce mode, restoring any modified profiles, patching the vulnerable application or package the attacker abused, removing unnecessary interpreter access and write permissions for the service, and adding detections for the same blocked shell, file, or socket behaviors across similar systems."""
references = [
    "https://cdn2.qualys.com/advisory/2026/03/10/crack-armor.txt",
    "https://blog.qualys.com/vulnerabilities-threat-research/2026/03/12/crackarmor-critical-apparmor-flaws-enable-local-privilege-escalation-to-root",
]
risk_score = 21
rule_id = "02137bc2-5cc2-4f7f-a8e4-c52dc239aa69"
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 no additional audit rules are required to be added to the integration.

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 = "low"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Auditd Manager",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.type == "change" and event.action == "violated-apparmor-policy"
'''

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

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Identifies User Account Control (UAC) bypass via eventvwr.exe. Attackers bypass UAC to stealthily execute code with
elevated permissions.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
]
language = "eql"
license = "Elastic License v2"
name = "Bypass UAC via Event Viewer"
risk_score = 73
rule_id = "31b4c719-f2b4-41f6-a9bd-fce93c2eaf62"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Windows Security Event Logs",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and
  process.parent.name : "eventvwr.exe" and
  not process.executable : (
        "?:\\Windows\\SysWOW64\\mmc.exe",
        "?:\\Windows\\System32\\mmc.exe",
        "?:\\Windows\\SysWOW64\\WerFault.exe",
        "?:\\Windows\\System32\\WerFault.exe",

        /* Crowdstrike specific exclusion as it uses NT Object paths */
        "\\Device\\HarddiskVolume*\\Windows\\Sys?????\\mmc.exe",
        "\\Device\\HarddiskVolume*\\Windows\\Sys?????\\WerFault.exe"
  )
'''

note = """## Triage and analysis

### Investigating Bypass UAC via Event Viewer

#### Possible investigation steps

- What did Event Viewer launch in the alert?
  - Focus: alert time, host/user scope, `process.parent.executable`, `process.executable`, `process.command_line`, and integrity level.
  - Implication: escalate when eventvwr.exe launches an unexpected high-integrity child or script/LOLBIN command instead of the normal console or error-reporting helper; lower suspicion only when path normalization proves helper behavior or fields match controlled UAC testing.

- Does the child payload identity and command line fit helper behavior or payload execution?
  - Focus: `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.command_line`.
  - Hint: use `process.pe.original_file_name` when path, filename, or signer conflicts suggest masquerading.
  - Implication: escalate when the child is unsigned, rare, user-writable, signer-mismatched, or runs PowerShell, cmd.exe, rundll32.exe, mshta.exe, wscript.exe, regsvr32.exe, remote retrieval, encoded content, or admin-path writes; lower suspicion only when identity, signer, hash history, and command intent fit controlled testing or helper behavior.

- What started Event Viewer, and did the session fit an interactive admin task?
  - Focus: recover the Event Viewer start using `host.id` + `process.parent.entity_id`, then review executable, command line, and logon type. $investigate_0
  - Hint: if `process.parent.entity_id` is absent, use `host.id` + `process.parent.pid` in a tight `@timestamp` window; PID-only recovery is weaker. Inspect `process.Ext.ancestry` only when direct lineage is incomplete.
  - Implication: escalate when Office, browser, archive, scripting, RMM, or remote/noninteractive activity launched Event Viewer; lower suspicion only when launcher and session also support controlled testing or helper behavior. Routine Event Viewer use should open Microsoft Management Console, not an arbitrary child.

- Is there corroborating current-user mscfile hijack evidence when process evidence stays suspicious?
  - Focus: if registry telemetry exists, review current-user mscfile shell-open command content, creator/deleter process, and timing; HKCU may render as HKEY_USERS\\<user SID>\\Software\\Classes\\mscfile\\shell\\open\\command.
  - Hint: use this as corroboration, not as a prerequisite for escalation. Missing registry telemetry is unresolved, not benign; absence of the key after the alert can mean cleanup.
  - Implication: escalate or raise confidence when the value points to the alert child, a script interpreter, a temp/user path, or was created or removed around the alert; lower suspicion only when artifact evidence fits the same confirmed test or helper behavior already supported by process evidence.

- What did the elevated child do next?
  - Focus: child process events where `process.parent.entity_id` matches `process.entity_id`; review executable, command line, and integrity level. $investigate_1
  - Hint: prefer entity-ID matches; if only PID matches are available, keep them tightly anchored to `@timestamp`.
  - Implication: escalate when the elevated child spawns shells, discovery, credential tools, droppers, installers, persistence helpers, or network-capable tooling; do not close on absent follow-on children when the original command, lineage, or mscfile evidence remains suspicious.

- Does the same Event Viewer payload pattern recur beyond this host?
  - Range: run only when local process, command, artifact, or lineage evidence remains suspicious or unresolved.
  - Focus: `process.hash.sha256`, stable command-line fragments, and `process.executable`, scoped by host and user.
    - $investigate_2
    - $investigate_3
  - Implication: broaden when the same payload or Event Viewer child pattern appears for unrelated hosts or users; keep locally scoped when recurrence is limited to the same confirmed test cohort and no contradictory local evidence remains.

- Based on the evidence gathered, what disposition is supported?
  - Escalate on strong local abuse signals across child behavior, payload identity, command intent, launcher/session, mscfile artifacts, follow-on children, or scope; close only when process evidence and recovery prove helper normalization or controlled testing; preserve evidence and escalate when registry corroboration is unavailable or evidence is mixed.

### False positive analysis

- This behavior is an operational anti-pattern. Realistic benign paths are controlled UAC testing or a sensor/path-normalization miss for expected Microsoft Management Console (mmc.exe) or Windows Error Reporting (WerFault.exe) child activity. Confirm identity, launcher/session context, command line, and any recovered mscfile artifact support the same benign explanation; if any dimension contradicts it, do not close as benign.
- Build exceptions from the minimum confirmed pattern: stable child hash or signer, exact Event Viewer parent-child relationship, bounded `user.id` and `host.id`, and test or normalization evidence. Avoid exceptions on `process.parent.name`, `process.name`, or `user.name` alone.

### Response and remediation

- If confirmed benign, document the exact evidence that resolved the alert, reverse temporary containment, and keep any exception scoped to the confirmed child identity, parent-child pattern, and host/user cohort.
- If suspicious but unconfirmed, preserve the alert, process event exports, Event Viewer parent and child entity IDs, command lines, hashes/signers, recovered mscfile value/history, child process tree, and process-scoped file or network indicators when available.
- After preservation, apply reversible containment tied to the findings, such as endpoint isolation for non-critical hosts or temporary egress restrictions for confirmed suspicious destinations. Weigh host criticality before isolation.
- If confirmed malicious, preserve the confirmed hashes/domains/destinations and elevated child process details, then isolate the host as needed, block confirmed malicious indicators, and suspend or terminate malicious processes only after recording their evidence.
- Eradicate only the artifacts found during triage: remove malicious payloads, restore the current-user mscfile handler to the expected mmc.exe behavior or remove the malicious override, clean related persistence, and remediate the entry vector that launched Event Viewer.
- Reset credentials or disable accounts only when process/session evidence shows credential exposure, explicit misuse, or attacker use of the affected `user.id`.
- After eradication, reduce repeat exposure by reviewing local administrator membership, using the highest feasible UAC prompt level, and patching affected Windows builds.
"""

setup = """## Setup

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

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

### Additional data sources

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

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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "host.id",
    "user.id",
    "process.entity_id",
    "process.pid",
    "process.name",
    "process.executable",
    "process.command_line",
    "process.hash.sha256",
    "process.code_signature.trusted",
    "process.Ext.token.integrity_level_name",
    "process.parent.entity_id",
    "process.parent.pid",
    "process.parent.name",
    "process.parent.executable",
]

[transform]

[[transform.investigate]]
label = "Event Viewer parent process event"
description = ""
providers = [
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.parent.entity_id}}", valueType = "string" }
  ],
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
    { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.pid", queryType = "phrase", value = "{{process.parent.pid}}", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "Process starts from the elevated child"
description = ""
providers = [
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
    { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
  ],
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
    { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.parent.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" }
  ]
]
relativeFrom = "now"
relativeTo = "now"

[[transform.investigate]]
label = "Recent process starts with the same child identity"
description = ""
providers = [
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
    { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" },
    { excluded = false, field = "process.hash.sha256", queryType = "phrase", value = "{{process.hash.sha256}}", valueType = "string" }
  ],
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
    { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" },
    { excluded = false, field = "process.executable", queryType = "phrase", value = "{{process.executable}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

[[transform.investigate]]
label = "Alerts associated with the user or host"
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" }
  ],
  [
    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

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

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

[[rule.threat.technique.subtechnique]]
id = "T1548.002"
name = "Bypass User Account Control"
reference = "https://attack.mitre.org/techniques/T1548/002/"

[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 = "T1548"
name = "Abuse Elevation Control Mechanism"
reference = "https://attack.mitre.org/techniques/T1548/"

[[rule.threat.technique.subtechnique]]
id = "T1548.002"
name = "Bypass User Account Control"
reference = "https://attack.mitre.org/techniques/T1548/002/"

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

[metadata]
creation_date = "2020/04/29"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/12/18"

[rule]
author = ["Elastic"]
description = """
Users can mark specific files as hidden simply by putting a "." as the first character in the file or folder name.
Adversaries can use this to their advantage to hide files and folders on the system for persistence and defense evasion.
This rule looks for hidden files or folders in common writable directories.
"""
false_positives = [
    """
    Certain tools may create hidden temporary files or directories upon installation or as part of their normal
    behavior. These events can be filtered by the process arguments, username, or process name values.
    """,
]
from = "now-9m"
index = ["logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
max_signals = 33
name = "Creation of Hidden Files and Directories via CommandLine"
risk_score = 21
rule_id = "b9666521-4742-49ce-9ddc-b8e84c35acae"
setup = """## Setup

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

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

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

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

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

#### The following steps should be executed in order to add the Auditbeat on a Linux System:
- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html).
- To run Auditbeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).
- To run Auditbeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html).
- For complete “Setup and Run Auditbeat” information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).

#### Custom Ingest Pipeline
For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the [guide](https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html).
"""
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
process.working_directory in ("/tmp", "/var/tmp", "/dev/shm") and
process.args regex~ """\.[a-z0-9_\-][a-z0-9_\-\.]{1,254}""" and
process.name like (
  "touch", "tee", "cp", "mv", "install", "dd", "vi", "vim", "nano", "truncate", "sed", "awk", "curl", "wget",
  "ftp", "scp", "rsync", "sftp", "tar", "unzip", "gunzip", "7z", "bzip2", "xz", "python*", "php*", "perl*",
  "ruby*", "node*", "java", "printf", "echo", "cat", ".*"
)
'''
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 Creation of Hidden Files and Directories via CommandLine

In Linux environments, files and directories prefixed with a dot (.) are hidden by default, a feature often exploited by adversaries to conceal malicious activities. Attackers may create hidden files in writable directories like /tmp to evade detection. The detection rule identifies suspicious processes creating such hidden files, excluding benign commands, to flag potential threats. This helps in uncovering stealthy persistence and defense evasion tactics.

### Possible investigation steps

- Review the process details to identify the command executed, focusing on the process.working_directory field to confirm if the hidden file was created in a common writable directory like /tmp, /var/tmp, or /dev/shm.
- Examine the process.args field to determine the specific hidden file or directory name created, and assess if it matches known malicious patterns or naming conventions.
- Check the process lineage by investigating the parent process to understand the context of how the hidden file creation was initiated and identify any potential malicious parent processes.
- Investigate the user account associated with the process to determine if it is a legitimate user or potentially compromised, and review recent activities by this user for any anomalies.
- Search for any additional hidden files or directories created around the same time or by the same process to identify further suspicious activities or artifacts.
- Correlate this event with other security alerts or logs from the same host to identify any related suspicious activities or patterns that could indicate a broader attack or compromise.

### False positive analysis

- System maintenance scripts may create hidden files in directories like /tmp for temporary storage. Review these scripts and consider excluding them if they are verified as non-threatening.
- Development tools and processes, such as version control systems or build scripts, might generate hidden files for configuration or state tracking. Identify these tools and add them to the exclusion list if they are part of regular operations.
- Monitoring and logging tools may use hidden files to store temporary data or logs. Verify these tools and exclude them if they are essential for system monitoring.
- User-specific applications or scripts might create hidden files for legitimate purposes. Conduct a review of user activities and exclude known benign applications to reduce noise.
- Automated backup or synchronization services could generate hidden files as part of their operation. Confirm these services and exclude them if they are part of the expected environment setup.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement.
- Terminate any suspicious processes identified by the detection rule that are creating hidden files in the specified directories.
- Remove any hidden files or directories created by unauthorized processes in the /tmp, /var/tmp, and /dev/shm directories to eliminate potential persistence mechanisms.
- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or related malicious activities.
- Restore any affected files or system components from a known good backup to ensure system integrity.
- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
- Implement enhanced monitoring and alerting for similar activities to improve detection and response capabilities for future incidents."""

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

[[rule.threat.technique]]
id = "T1564"
name = "Hide Artifacts"
reference = "https://attack.mitre.org/techniques/T1564/"

[[rule.threat.technique.subtechnique]]
id = "T1564.001"
name = "Hidden Files and Directories"
reference = "https://attack.mitre.org/techniques/T1564/001/"

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

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

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

[metadata]
creation_date = "2025/01/16"
integration = ["endpoint", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
This rule detects the creation of D-Bus service files on Linux systems. D-Bus is a message bus system that provides a
way for applications to talk to one another. D-Bus services are defined in service files that are typically located in
default directories. The rule looks for the creation of service files that are not associated with known package
managers or system services. Attackers may create malicious D-Bus services to establish persistence or escalate
privileges on a system.
"""
from = "now-9m"
index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
language = "eql"
license = "Elastic License v2"
name = "D-Bus Service Created"
note = """## Triage and analysis

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

### Investigating D-Bus Service Created

D-Bus is an inter-process communication system in Linux, enabling applications to communicate. Adversaries may exploit D-Bus by creating unauthorized service files to maintain persistence or escalate privileges. The detection rule identifies suspicious service file creations in key directories, excluding known legitimate processes, to flag potential malicious activity.

### Possible investigation steps

- Review the file path and extension to confirm if the created file is located in one of the monitored directories such as /usr/share/dbus-1/system-services/ or /etc/dbus-1/system.d/, and ensure it has a .service or .conf extension.
- Examine the process executable that created the file to determine if it is listed as a known legitimate process in the exclusion list. If not, investigate the process further to understand its origin and purpose.
- Check the process name and path for any unusual or unexpected patterns, especially if it is not part of the known exclusions like ssm-agent-worker or platform-python*.
- Investigate the file creation time and correlate it with other system activities or logs to identify any suspicious behavior or patterns around the time of the alert.
- Look into the user account associated with the process that created the file to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior.
- Search for any related alerts or logs that might indicate a broader attack pattern, such as other unauthorized file creations or modifications in the system.

### False positive analysis

- Package manager operations can trigger false positives when legitimate service files are created during software installations or updates. To manage this, exclude processes associated with known package managers like dpkg, rpm, and yum from the detection rule.
- System service updates may also result in false positives. Exclude processes such as systemd and crond that are responsible for legitimate system service management.
- Development and testing environments often involve the creation of temporary or test service files. Exclude paths and processes specific to these environments, such as those under /tmp or /dev/fd, to reduce noise.
- Automation tools like Puppet and Chef can create service files as part of their configuration management tasks. Exclude these tools by adding their executable paths to the exception list.
- Custom scripts or tools that mimic package manager behavior might also cause false positives. Identify and exclude these specific scripts or tools by their process names or paths if they are known to be benign.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
- Terminate any suspicious processes associated with the creation of unauthorized D-Bus service files to halt potential malicious activity.
- Remove any unauthorized D-Bus service files identified in the specified directories to eliminate persistence mechanisms.
- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized privilege escalation has occurred.
- Restore the system from a known good backup if unauthorized changes or damage to the system are detected.
- Monitor the system and network for any signs of re-infection or similar suspicious activities, using enhanced logging and alerting mechanisms.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected."""
risk_score = 21
rule_id = "952c92af-d67f-4f01-8a9c-725efefa7e07"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

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

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

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Privilege Escalation",
    "Data Source: Elastic Defend",
    "Data Source: SentinelOne",
    "Data Source: Elastic Endgame",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.type == "creation" and process.executable != null and
file.extension in ("service", "conf") and file.path like (
  "/usr/share/dbus-1/system-services/*", "/etc/dbus-1/system.d/*",
  "/lib/dbus-1/system-services/*", "/run/dbus/system.d/*",
  "/home/*/.local/share/dbus-1/services/*", "/home/*/.dbus/session-bus/*",
  "/usr/share/dbus-1/services/*", "/etc/dbus-1/session.d/*"
) and not (
  process.executable in (
    "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf",
    "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum",
    "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic",
    "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk",
    "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet",
    "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client",
    "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon",
    "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/bin/crio", "/usr/sbin/crond",
    "/opt/puppetlabs/puppet/bin/ruby", "/usr/libexec/platform-python", "/kaniko/kaniko-executor",
    "/usr/local/bin/dockerd", "/usr/bin/podman", "/bin/install", "/proc/self/exe", "/usr/lib/systemd/systemd",
    "/usr/sbin/sshd", "/usr/bin/gitlab-runner", "/opt/gitlab/embedded/bin/ruby", "/usr/sbin/gdm", "/usr/bin/install",
    "/usr/local/manageengine/uems_agent/bin/dcregister", "./usr/bin/podman", "/.envbuilder/bin/envbuilder"
  ) or
  process.executable like (
    "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*",
    "/var/lib/docker/overlay2/*/dockerd", "/var/lib/containers/storage/overlay/*/dockerd"
  ) or
  process.name like (
    "ssm-agent-worker", "platform-python*", "dnf_install", "cloudflared", "lxc-pve-prestart-hook",
    "convert-usrmerge", "elastic-agent", "google_metadata_script_runner", "update-alternatives", "gitlab-runner",
    "install", "crio", "apt-get", "package-cleanup", "dcservice", "dcregister", "jumpcloud-agent", "executor"
  ) or
  (process.name == "sed" and file.name like "sed*") or
  (process.name == "perl" and file.name like "e2scrub_all.tmp*") 
)
'''

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

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

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

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

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

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

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

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

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

[rule]
author = ["Elastic"]
description = """
This rule monitors for the addition of an executable bit for scripts that are located in directories which are commonly
abused for persistence. An alert of this rule is an indicator that a persistence mechanism is being set up within your
environment. Adversaries may create these scripts to execute malicious code at start-up, or at a set interval to gain
persistence onto the system.
"""
from = "now-9m"
index = ["logs-endpoint.events.process*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
language = "eql"
license = "Elastic License v2"
name = "Executable Bit Set for Potential Persistence Script"
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 Executable Bit Set for Potential Persistence Script

In Linux environments, scripts with executable permissions can be used to automate tasks, including system start-up processes. Adversaries exploit this by setting executable bits on scripts in directories typically used for persistence, allowing malicious code to run automatically. The detection rule identifies such activities by monitoring for changes in executable permissions in these directories, signaling potential unauthorized persistence attempts.

### Possible investigation steps

- Review the process details to identify the specific script or file that had its executable bit set, focusing on the process.args field to determine the exact file path.
- Examine the process.parent.executable field to understand the parent process that initiated the permission change, which can provide context on whether the action was part of a legitimate process or potentially malicious activity.
- Check the user account associated with the process to determine if the action was performed by a legitimate user or a compromised account.
- Investigate the history of the file in question, including recent modifications and the creation date, to assess if it aligns with known system changes or updates.
- Analyze the contents of the script or file to identify any suspicious or unauthorized code that could indicate malicious intent.
- Correlate this event with other recent alerts or logs from the same host to identify patterns or additional indicators of compromise that may suggest a broader persistence mechanism.

### False positive analysis

- System administrators or automated scripts may legitimately change executable permissions in directories like /etc/init.d or /etc/cron* for maintenance or updates. To handle these, create exceptions for known administrative scripts or processes that regularly perform these actions.
- Software installations or updates might trigger this rule when they modify startup scripts or configuration files. Users can mitigate this by excluding processes originating from trusted package managers or installation paths, such as /var/lib/dpkg.
- Custom user scripts in home directories, especially in /home/*/.config/autostart, may be flagged if users set them to run at startup. To reduce false positives, maintain a whitelist of user scripts that are known and approved for startup execution.
- Security tools or monitoring solutions might adjust permissions as part of their operations. Identify these tools and exclude their processes from triggering the rule to prevent unnecessary alerts.

### Response and remediation

- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
- Terminate any suspicious processes identified in the alert that are associated with unauthorized script execution.
- Remove or disable the executable permissions on the identified scripts to prevent further unauthorized execution.
- Conduct a thorough review of the affected directories to identify and remove any additional unauthorized scripts or files.
- Restore any modified system files or configurations from a known good backup to ensure system integrity.
- Monitor the system for any signs of re-infection or further unauthorized changes, focusing on the directories and processes highlighted in the alert.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected."""
references = [
    "https://www.intezer.com/blog/malware-analysis/hiddenwasp-malware-targeting-linux-systems/",
    "https://pberba.github.io/security/2022/02/06/linux-threat-hunting-for-persistence-initialization-scripts-and-shell-configuration/#8-boot-or-logon-initialization-scripts-rc-scripts",
    "https://www.cyberciti.biz/faq/how-to-enable-rc-local-shell-script-on-systemd-while-booting-linux-system/",
    "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms",
]
risk_score = 47
rule_id = "94418745-529f-4259-8d25-a713a6feb6ae"
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",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: SentinelOne",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and
process.args : (
  // Misc.
  "/etc/rc.local", "/etc/rc.common", "/etc/rc.d/rc.local", "/etc/init.d/*", "/etc/update-motd.d/*",
  "/etc/apt/apt.conf.d/*", "/etc/cron*", "/etc/init/*", "/etc/NetworkManager/dispatcher.d/*",
  "/lib/dracut/modules.d/*", "/usr/lib/dracut/modules.d/*",

  // XDG
  "/etc/xdg/autostart/*", "/home/*/.config/autostart/*", "/root/.config/autostart/*",
  "/home/*/.local/share/autostart/*", "/root/.local/share/autostart/*", "/home/*/.config/autostart-scripts/*",
  "/root/.config/autostart-scripts/*", "/etc/xdg/autostart/*", "/usr/share/autostart/*",

  // udev
  "/lib/udev/*", "/etc/udev/rules.d/*", "/usr/lib/udev/rules.d/*", "/run/udev/rules.d/*"

) and (
  (process.name == "chmod" and process.args : ("+x*", "1*", "3*", "5*", "7*")) or
  (process.name == "install" and process.args : "-m*" and process.args : ("7*", "5*", "3*", "1*"))
) and not (
  process.parent.executable : "/var/lib/dpkg/*" or
  process.command_line in ("chmod 777 /etc/update-motd.d/", "chmod 755 /etc/update-motd.d/")
)
'''

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

[[rule.threat.technique]]
id = "T1037"
name = "Boot or Logon Initialization Scripts"
reference = "https://attack.mitre.org/techniques/T1037/"

[[rule.threat.technique.subtechnique]]
id = "T1037.004"
name = "RC Scripts"
reference = "https://attack.mitre.org/techniques/T1037/004/"

[[rule.threat.technique]]
id = "T1053"
name = "Scheduled Task/Job"
reference = "https://attack.mitre.org/techniques/T1053/"

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

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

[[rule.threat.technique.subtechnique]]
id = "T1546.017"
name = "Udev Rules"
reference = "https://attack.mitre.org/techniques/T1546/017/"

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

[[rule.threat.technique.subtechnique]]
id = "T1547.013"
name = "XDG Autostart Entries"
reference = "https://attack.mitre.org/techniques/T1547/013/"

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

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

[[rule.threat.technique]]
id = "T1222"
name = "File and Directory Permissions Modification"
reference = "https://attack.mitre.org/techniques/T1222/"

[[rule.threat.technique.subtechnique]]
id = "T1222.002"
name = "Linux and Mac File and Directory Permissions Modification"
reference = "https://attack.mitre.org/techniques/T1222/002/"

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

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

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Identifies Microsoft Purview Insider Risk Management signals including alerts, cases, scoped user insights, HR signals,
and physical badging signals. These events indicate potential insider threats, compromised user accounts, or anomalous
user behavior patterns detected by Microsoft's behavioral analytics. This building block rule generates security events
for correlation, threat hunting, and telemetry collection to support detection of insider threats and account compromise.
"""
from = "now-9m"
index = ["logs-o365.audit-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "M365 Purview Insider Risk Signal"
references = [
    "https://learn.microsoft.com/en-us/purview/insider-risk-management",
    "https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-schema#enum-auditlogrecordtype---type-edmint32",
]
risk_score = 21
rule_id = "f2c43e8c-ccf2-4eab-9e9a-e335da253773"
setup = """### Additional notes

For information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).
"""
severity = "low"
tags = [
    "Domain: Cloud",
    "Domain: SaaS",
    "Data Source: Microsoft 365",
    "Data Source: Microsoft 365 Audit Logs",
    "Data Source: Microsoft Purview",
    "Data Source: Microsoft Purview Insider Risk",
    "Use Case: Threat Detection",
    "Use Case: Insider Threat Detection",
    "Tactic: Collection",
    "Tactic: Exfiltration",
    "Tactic: Impact",
    "Rule Type: BBR",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.dataset:o365.audit and
    event.code:(PurviewInsiderRiskCases or PurviewInsiderRiskAlerts or InsiderRiskScopedUserInsights or InsiderRiskScopedUsers or InformationWorkerProtection or HRSignal or PhysicalBadgingSignal)
'''


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

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

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

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

[metadata]
creation_date = "2025/07/24"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
This rule detects the execution of multiple base64 decoding commands to decode data. multi-decoded
data is suspicious, and may be used by attackers to obfuscate malicious payloads or commands.
"""
from = "now-9m"
index = ["logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Multi-Base64 Decoding Attempt from Suspicious Location"
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 Multi-Base64 Decoding Attempt from Suspicious Location

Base64 encoding is a common method to encode binary data into ASCII text, often used for data transmission. Adversaries exploit this by encoding malicious payloads to evade detection. The detection rule identifies suspicious decoding activities, especially from unusual directories, by monitoring rapid sequences of decoding commands. It excludes benign processes to reduce false positives, focusing on potential threats in Linux environments.

### Possible investigation steps

- Review the process details, including the parent entity ID and executable path, to understand the context of the decoding activity and identify the parent process responsible for initiating the base64 commands.
- Examine the working directory where the decoding occurred, focusing on suspicious locations such as "/tmp/*", "/var/tmp*", "/dev/shm/*", "/var/www/*", "/home/*", and "/root/*" to determine if the activity aligns with typical usage patterns or if it indicates potential malicious behavior.
- Analyze the command-line arguments used in the decoding process, specifically looking for "-d*" or "--d*" flags, to assess whether the decoding was intended to obfuscate data or execute hidden payloads.
- Investigate the sequence of events within the 3-second maxspan to identify any rapid or automated decoding attempts that could suggest scripted or malicious activity.
- Check for any exclusions in the rule, such as known benign processes or directories, to ensure the alert is not a false positive and the activity is genuinely suspicious.
- Correlate the alert with other security events or logs from the same host or network segment to gather additional context and determine if this is part of a larger attack or isolated incident.

### False positive analysis

- Scheduled tasks or cron jobs may trigger base64 decoding in benign processes. Exclude known executables like "/etc/cron.daily/vivaldi" and "/etc/cron.daily/opera-browser" to reduce false positives.
- System management tools or agents, such as those located in "/opt/microsoft/omsagent/plugin" or "/opt/rapid7/ir_agent/*", might use base64 decoding for legitimate purposes. Add these directories to the exclusion list to prevent unnecessary alerts.
- Temporary directories like "/tmp/newroot/*" may be used by legitimate applications for transient data processing. Consider excluding these paths if they are frequently involved in non-malicious activities.
- User scripts or applications in home directories may use base64 for encoding or decoding data. Monitor and whitelist specific user processes that are known to be safe to avoid false positives.
- Regularly review and update the exclusion list based on observed benign activities to ensure the rule remains effective without generating excessive false alerts.

### Response and remediation

- Immediately isolate the affected system to prevent further execution of potentially malicious payloads. Disconnect the system from the network to contain the threat.

- Review and terminate any suspicious processes identified by the detection rule, particularly those involving base64 decoding from unusual directories. Use process management tools to kill these processes.

- Conduct a thorough examination of the directories flagged by the alert (e.g., /tmp, /var/tmp, /dev/shm) to identify and remove any malicious files or scripts. Ensure these directories are cleaned of unauthorized or suspicious content.

- Restore the system from a known good backup if any malicious activity is confirmed, ensuring that the backup is free from compromise.

- Escalate the incident to the security operations team for further investigation and analysis. Provide them with logs and details of the processes and directories involved for deeper threat assessment.

- Implement additional monitoring and alerting for similar suspicious activities, focusing on rapid sequences of base64 decoding commands and unusual directory usage to enhance detection capabilities.

- Review and update access controls and permissions for the directories involved to prevent unauthorized access and execution of potentially harmful scripts or binaries.
"""
risk_score = 47
rule_id = "03d856c2-7f74-4540-a530-e20af5e39789"
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",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Tactic: Execution",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide"
]
type = "eql"
query = '''
sequence by process.parent.entity_id with maxspan=3s
  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.parent.executable != null and
   process.name in ("base64", "base64plain", "base64url", "base64mime", "base64pem", "base32", "base16") and
   // Only including potentially suspicious locations
   process.args like~ ("-d*", "--d*") and process.working_directory like (
     "/tmp/*", "/var/tmp*", "/dev/shm/*", "/var/www/*", "/home/*", "/root/*"
   ) and not (
     process.parent.executable in (
       "/usr/share/ec2-instance-connect/eic_curl_authorized_keys", "/etc/cron.daily/vivaldi",
       "/etc/cron.daily/opera-browser"
     ) or
     process.working_directory like (
       "/opt/microsoft/omsagent/plugin", "/opt/rapid7/ir_agent/*", "/tmp/newroot/*"
      ) or
      (process.parent.name == "zsh" and process.parent.command_line like "*extendedglob*")
   )]
  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.parent.executable != null and
   process.name in ("base64", "base64plain", "base64url", "base64mime", "base64pem", "base32", "base16") and
   process.args like~ ("-d*", "--d*")]
'''

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

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

[[rule.threat.technique.subtechnique]]
id = "T1027.010"
name = "Command Obfuscation"
reference = "https://attack.mitre.org/techniques/T1027/010/"

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

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

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

[[rule.threat.technique]]
id = "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 = "T1204"
name = "User Execution"
reference = "https://attack.mitre.org/techniques/T1204/"

[[rule.threat.technique.subtechnique]]
id = "T1204.002"
name = "Malicious File"
reference = "https://attack.mitre.org/techniques/T1204/002/"

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

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

[rule]
author = ["Elastic"]
description = """
Detects possible Denial of Service (DoS) attacks against an Okta organization. An adversary may attempt to disrupt an
organization's business operations by performing a DoS attack against its Okta service.
"""
index = ["filebeat-*", "logs-okta*"]
language = "kuery"
license = "Elastic License v2"
name = "Possible Okta DoS Attack"
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 Possible Okta DoS Attack

Okta, a leading identity management service, is crucial for managing user access in organizations. Adversaries may exploit Okta by overwhelming it with requests, causing service disruptions. The detection rule identifies potential DoS attacks by monitoring specific Okta system events that indicate rate limit violations, signaling attempts to degrade service availability.

### Possible investigation steps

- Review the specific Okta system events that triggered the alert, focusing on event.action values such as application.integration.rate_limit_exceeded, system.org.rate_limit.warning, system.org.rate_limit.violation, and core.concurrency.org.limit.violation to understand the nature of the rate limit violations.
- Analyze the frequency and pattern of the triggered events to determine if there is a consistent or unusual spike in requests that could indicate a DoS attack.
- Identify the source IP addresses or user accounts associated with the excessive requests to determine if they are legitimate users or potential adversaries.
- Check for any recent changes or updates in the Okta configuration or integrations that might have inadvertently caused an increase in request rates.
- Correlate the Okta events with other network or application logs to identify any broader patterns or simultaneous attacks on other services that might suggest a coordinated effort.

### False positive analysis

- High-volume legitimate user activity can trigger rate limit warnings. Monitor for patterns of normal usage spikes, such as during company-wide meetings or product launches, and consider setting exceptions for these events.
- Automated processes or integrations that frequently interact with Okta may cause rate limit violations. Identify these processes and adjust their request rates or set exceptions to prevent false positives.
- Scheduled batch jobs that access Okta services might exceed rate limits. Review and optimize the scheduling of these jobs to distribute the load more evenly or whitelist them if they are essential and non-disruptive.
- Third-party applications integrated with Okta could inadvertently cause rate limit issues. Work with vendors to ensure their applications are optimized for Okta's rate limits or create exceptions for trusted applications.
- Temporary spikes in user activity due to password resets or account provisioning can lead to false positives. Implement monitoring to distinguish between these benign activities and potential threats, and adjust the rule to accommodate expected spikes.

### Response and remediation

- Immediately assess the impact on business operations by checking the availability and performance of Okta services. Coordinate with IT teams to ensure critical services remain operational.
- Contain the attack by implementing rate limiting or IP blocking for the identified sources of excessive requests. Use network security tools to enforce these restrictions.
- Notify the security operations center (SOC) and relevant stakeholders about the potential DoS attack to ensure awareness and coordinated response efforts.
- Review and adjust Okta's rate limit settings to mitigate the risk of future DoS attempts, ensuring they align with the organization's typical usage patterns.
- Escalate the incident to Okta support for further investigation and assistance in mitigating the attack, providing them with relevant logs and event details.
- Conduct a post-incident analysis to identify any gaps in the current security posture and update incident response plans accordingly.
- Enhance monitoring and alerting for similar threats by refining detection rules and ensuring they are tuned to capture early indicators of rate limit violations.

## Setup

The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://developer.okta.com/docs/reference/api/system-log/",
    "https://developer.okta.com/docs/reference/api/event-types/",
    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
]
risk_score = 47
rule_id = "e6e3ecff-03dd-48ec-acbd-54a04de10c68"
severity = "medium"
tags = [
    "Use Case: Identity and Access Audit",
    "Data Source: Okta",
    "Tactic: Impact",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:okta.system and event.action:(application.integration.rate_limit_exceeded or system.org.rate_limit.warning or system.org.rate_limit.violation or core.concurrency.org.limit.violation)
'''


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

[[rule.threat.technique]]
id = "T1498"
name = "Network Denial of Service"
reference = "https://attack.mitre.org/techniques/T1498/"

[[rule.threat.technique]]
id = "T1499"
name = "Endpoint Denial of Service"
reference = "https://attack.mitre.org/techniques/T1499/"

[[rule.threat.technique.subtechnique]]
id = "T1499.002"
name = "Service Exhaustion Flood"
reference = "https://attack.mitre.org/techniques/T1499/002/"

[[rule.threat.technique.subtechnique]]
id = "T1499.003"
name = "Application Exhaustion Flood"
reference = "https://attack.mitre.org/techniques/T1499/003/"

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

[metadata]
creation_date = "2023/08/28"
integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2026/01/18"

[rule]
author = ["Elastic"]
description = """
This rule monitors for potential attempts to disable AppArmor. AppArmor is a Linux security module that enforces
fine-grained access control policies to restrict the actions and resources that specific applications and processes can
access. Adversaries may disable security tools to avoid possible detection of their tools and activities.
"""
from = "now-9m"
index = [
    "auditbeat-*",
    "endgame-*",
    "logs-auditd_manager.auditd-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Potential Disabling of AppArmor"
note = """## Triage and analysis

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

### Investigating Potential Disabling of AppArmor

AppArmor is a Linux security module that enforces strict access controls, limiting what applications can do. Adversaries may attempt to disable AppArmor to evade detection and freely execute malicious activities. The detection rule identifies suspicious processes attempting to stop or disable AppArmor services, such as using commands like `systemctl` or `service` with specific arguments, indicating potential tampering with security defenses.

### Possible investigation steps

- Review the process details to confirm the command used, focusing on the process name and arguments, such as "systemctl", "service", "chkconfig", or "ln" with arguments related to AppArmor.
- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised.
- Investigate the host's recent activity logs to identify any other suspicious behavior or anomalies around the time the alert was triggered.
- Examine the system's AppArmor status to verify if it has been disabled or tampered with, and assess any potential impact on system security.
- Correlate this event with other alerts or logs from the same host or user to identify patterns or a broader attack campaign.
- Consult threat intelligence sources to determine if there are known adversaries or malware that commonly attempt to disable AppArmor in similar ways.

### False positive analysis

- Routine system maintenance activities may trigger this rule, such as administrators stopping AppArmor for legitimate updates or configuration changes. To manage this, create exceptions for known maintenance windows or specific administrator accounts.
- Automated scripts or configuration management tools like Ansible or Puppet might stop or disable AppArmor as part of their deployment processes. Identify these scripts and whitelist their execution paths or associated user accounts.
- Testing environments where security modules are frequently enabled and disabled for testing purposes can generate false positives. Consider excluding these environments from the rule or adjusting the rule's sensitivity for these specific hosts.
- Some legitimate software installations may require temporarily disabling AppArmor. Monitor installation logs and correlate them with the rule triggers to identify and exclude these benign activities.
- In environments where AppArmor is not actively used or managed, the rule may trigger on default system actions. Evaluate the necessity of monitoring AppArmor in such environments and adjust the rule scope accordingly.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary.
- Terminate any suspicious processes identified by the detection rule, specifically those attempting to disable AppArmor, to halt any ongoing malicious activities.
- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or related malicious activities.
- Restore AppArmor to its intended operational state by re-enabling the service and ensuring all security policies are correctly applied.
- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.
- Implement enhanced monitoring on the affected system and similar environments to detect any future attempts to disable AppArmor or other security controls.
- Review and update access controls and permissions to ensure that only authorized personnel can modify security settings, reducing the risk of similar incidents."""
risk_score = 73
rule_id = "fac52c69-2646-4e79-89c0-fd7653461010"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

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

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

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Data Source: Elastic Endgame",
    "Data Source: Auditd Manager",
    "Data Source: Crowdstrike",
    "Data Source: SentinelOne",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
(
  (process.name == "systemctl" and process.args in ("disable", "stop", "kill", "mask") and process.args in ("apparmor", "apparmor.service")) or
  (process.name == "service" and process.args == "apparmor" and process.args == "stop") or
  (process.name == "chkconfig" and process.args == "apparmor" and process.args == "off") or
  (process.name == "update-rc.d" and process.args == "apparmor" and process.args in ("remove", "disable")) or
  (process.name == "ln" and process.args : "/etc/apparmor.d/*" and process.args == "/etc/apparmor.d/disable/")
) and
not ?process.parent.executable == "/opt/puppetlabs/puppet/bin/ruby"
'''

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

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

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

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

[metadata]
creation_date = "2025/02/03"
integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
Identifies Curl for Windows making an HTTP request. Adversaries could abuse Curl to download files or upload data to a
remote URL.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
]
language = "eql"
license = "Elastic License v2"
name = "Potential File Transfer via Curl for Windows"
note = """## Triage and analysis

### Investigating Potential File Transfer via Curl for Windows

This rule identifies the use of Curl for Windows to download files from a remote URL or post data to a remote site.

#### Possible investigation steps

- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
- Identify the user account that performed the action and whether it should perform this kind of action.
- Contact the account owner and confirm whether they are aware of this activity.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.
- Examine the details of the dropped file, and whether it was executed.
- Check the reputation of the domain or IP address used to host the downloaded file or if the user downloaded the file from an internal system.
- Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.

### False positive analysis

- This activity is unusual but can be done by administrators. Benign true positives (B-TPs) can be added as exceptions if necessary.

### Response and remediation

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

setup = """## Setup

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

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

### Additional data sources

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

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

references = ["https://attack.mitre.org/techniques/T1105/"]
risk_score = 21
rule_id = "2e0051cb-51f8-492f-9d90-174e16b5e96b"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Command and Control",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Windows Security Event Logs",
    "Data Source: Microsoft Defender XDR",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
    "Data Source: Sysmon",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and
  process.executable : (
    "?:\\Windows\\System32\\curl.exe",
    "?:\\Windows\\SysWOW64\\curl.exe"
  ) and
  process.command_line : "*http*" and
  process.parent.name : (
    "cmd.exe", "powershell.exe",
    "rundll32.exe", "explorer.exe",
    "conhost.exe", "forfiles.exe",
    "wscript.exe", "cscript.exe",
    "mshta.exe", "hh.exe", "mmc.exe"
  ) and 
  not (
    ?user.id == "S-1-5-18" and
    /* Don't apply the user.id exclusion to Sysmon for compatibility */
    not data_stream.dataset : ("windows.sysmon_operational", "windows.sysmon")
  ) and
  /* Exclude System Integrity Processes for Sysmon */
  not ?winlog.event_data.IntegrityLevel == "System"
'''


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

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

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

[[rule.threat.technique]]
id = "T1105"
name = "Ingress Tool Transfer"
reference = "https://attack.mitre.org/techniques/T1105/"

[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 = "T1567"
name = "Exfiltration Over Web Service"
reference = "https://attack.mitre.org/techniques/T1567/"

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

[rule]
description = """
This rule monitors for the execution of a suspicious sudo command that is leveraged in CVE-2019-14287 to escalate
privileges to root. Sudo does not verify the presence of the designated user ID and proceeds to execute using a user ID
that can be chosen arbitrarily. By using the sudo privileges, the command "sudo -u#-1" translates to an ID of 0,
representing the root user. This exploit may work for sudo versions prior to v1.28.
"""
id = "b382c343-892d-46e1-8fad-22576a086598"
license = "Elastic License v2"
name = "Potential Sudo Privilege Escalation via CVE-2019-14287"
os_list = ["linux"]
reference = ["https://www.exploit-db.com/exploits/47502"]
version = "1.0.5"

query = '''
process where event.action == "exec" and event.type == "start" and process.name == "sudo" and process.args == "-u#-1"
'''

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

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


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

[internal]
min_endpoint_version = "7.15.0"

[rule]
description = """
Identifies potential remote process manipulation using SetThreadContext API. This may indicate an attempt to inject code
or debug a remote process.
"""
id = "c456266f-e920-4acb-9b32-711fa7b94ca5"
license = "Elastic License v2"
name = "Remote Thread Context Manipulation"
os_list = ["windows"]
reference = ["https://www.elastic.co/security-labs/doubling-down-etw-callstacks"]
version = "1.0.30"

query = '''
api where 
  process.Ext.api.name : ("SetThreadContext", "Wow64SetThreadContext") and 
  process.executable != null and 
  ((process.Ext.api.behaviors == "cross-process" and process.Ext.api.behaviors == "execute_shellcode") or process.Ext.api.behaviors == "hardware_breakpoint_set") and
  not process.Ext.api.summary : "*OSError*" and process.thread.Ext.call_stack_final_user_module.name != null and
  (process.thread.Ext.call_stack_final_user_module.hash.sha256 like "?*" or
   process.thread.Ext.call_stack_summary == "ntdll.dll|kernelbase.dll|Unbacked") and
  not (process.code_signature.subject_name :
               ("Duncan Ogilvie", "International Business Machines Corporation", "COGNOSPHERE PTE. LTD.",
                "CAPCOM CO., LTD.", "Larian Studios Games Ltd.", "Valve Corp.", "Rockstar Games, Inc.",
                "Johannes Schindelin", "Unity Technologies ApS",
                "Paradox Interactive AB (publ)", "CD PROJEKT SPÓŁKA AKCYJNA", "JetBrains s.r.o.",
                "Open Source Developer, Maksim Moisiuk", "Take-Two Interactive Software, Inc.",
                "Facepunch Studios Ltd", "Nox Limited", "Maksim Moisiuk",
                "Activision Publishing Inc", "OpenJS Foundation", "Ubisoft Entertainment Sweden AB", 
                "Epic Games Inc.", "NEXON Korea Corporation.", "Molotov", "Agilebits", "Gaijin Network Ltd", "Open Source Developer, Duncan Ogilvie",
                "COMPUTACION EN ACCION SA DE CV", "MPTronic", "Docker Inc", "Embark Studios AB", "Piriform Software Ltd", "Unity Technologies SF") and
      process.code_signature.trusted == true) and 
 not process.thread.Ext.call_stack_final_user_module.name like ("Kernel", "Unknown", "dbgeng.dll", "Undetermined") and
 not process.thread.Ext.call_stack_final_user_module.protection_provenance like ("Kernel", "kernel|*") and
 not (process.code_signature.trusted == true and stringcontains~(process.executable, process.thread.Ext.call_stack_final_user_module.path)) and 
 not process.thread.Ext.call_stack_final_user_module.path : 
                                               ("?:\\Program Files\\*", 
                                                "?:\\Program Files (x86)\\*", 
                                                "\\Program Files\\*", 
                                                "\\Program Files (x86)\\*") and 
 not process.thread.Ext.call_stack_final_user_module.hash.sha256 in
                        ("31f65b7afe91e23ae88d8229fd54c5eb494ffd4594bdc3d6a91d2d69892b284b",
                         "766ac0f768c5b2acb19ecb8cf179c59d56b74d71437f5d1331408d9c827cfde8",
                         "67ca92cc7beea130c6f7e8f3982f3256f1724f22c6de869a884df47dcc0b7b95",
                         "b6a39ef455952471c935ea190a78eecf423fba2a49ffce1afdf737d58bb2c9d3",
                         "062a170de010b5be0840dd92a9ad43da1d1e09738956cffce78368305afe885b",
                         "2c5e3525840ef01510583ecc37f876791b2d6e73fbe8099c93ab0f5787ba626d",
                         "655d6df92eef4c947498456d40b7856cbe72ede8c6432072f968207817825b52",
                         "8b451b88d2cc91b079251e2347abb84d2b09712512fa9e57d9de35e93c751863",
                         "615ac4399eed0a26e5cd9bba4e7dcf661400fb0546dce067523fe275351d3b04",
                         "22a8ae4f904366c8f42d8da22df28c755cefd28ab34268c77275229964e34c66",
                         "6957d81c1fb22b7a2c88dd63f1c99a777805d13e0d0af6411a46c1f40e8b22e9",
                         "2dfa7a9d8be474447f8ea53dc864a5bb8cdcc526664636154adfa8b71386f883",
                         "e3fdcd2b4c5215e74b0cabe91ce7fe2800cbf8e2a28157342960bca61bbd6b5d",
                         "f1b668a9cca5c832ae8374c1815cfc8fcb452d05268797f0c022d74000ecd486",
                         "c0a45f327f40cf8cdc79dc9cccf858ae862a6df0a26c83141cb3c24fc604b483",
                         "8fb6e0cd1c0d01157ee1a87da9e894f7451988a5349cff5d99f2d3d9c6ffc397",
                         "4c6bbe178708b9590be27d8423261d6c1abfcdfe6cf90df1654ff60033a48bee",
                         "7eda2d6011ed2dae3f0c2ec30bdd2ae0c0146bf1baaa827dccb002b6ad793820",
                         "60ac461ca948a8a26dc3013d3b30fa615666b0d3fe8f5014dfd39a5de5440868",
                         "1165eb20cab73c780b439fdbea3fd9c6545f1d5488bf6c6194bf4dd49450f618",
                         "79ab757eaf9d745e9da693510c58b180ac45d6450d8df2260826c285bfe0f2de") and
 not process.executable : ("D:\\laragon\\bin\\php\\php-8.0.25-nts-Win32-vs16-x64\\php.exe", 
                           "D:\\laragon\\bin\\php\\php-8.2.4-nts-Win32-vs16-x64\\php.exe", 
                           "Z:\\SteamLibrary\\steamapps\\common\\*.exe",
                           "D:\\SteamLibrary\\steamapps\\common\\*.exe",
                           "D:\\Steam\\steamapps\\common\\*.exe",
                           "D:\\Visual Studio\\Common7\\IDE\\devenv.exe",
                           "?:\\Program Files\\DebugDiag\\DbgHost.exe",
                           "?:\\Program Files\\Git\\usr\\bin\\env.exe",
                           "?:\\Program Files\\Microsoft Visual Studio*\\Common?\\IDE\\*.exe",
                           "?:\\Program Files (x86)\\Microsoft Visual Studio*\\Common?\\IDE\\*.exe",
                           "?:\\Program Files (x86)\\Steam\\steamapps\\common\\*.exe",
                           "?:\\Program Files\\Microsoft Visual Studio\\2022\\Professional\\Common7\\IDE\\devenv.exe",
                           "?:\\Program Files (x86)\\WinHex 19.6 Portable\\WinHex64.exe",
                           "?:\\Program Files\\JetBrains\\*\\plugins\\go\\lib\\dlv\\windows\\dlv.exe") and
 not process.parent.executable :
                     ("?:\\Program Files\\cmder\\vendor\\conemu-maximus?\\ConEmu\\ConEmuC64.exe",
                      "C:\\Program Files (x86)\\GitExtensions\\ConEmu\\ConEmuC64.exe",
                      "C:\\Program Files\\Git\\mingw64\\libexec\\git-core\\git-remote-https.exe",
                      "C:\\Program Files\\Git\\usr\\bin\\bash.exe") and
 not (process.name : ("cmd.exe", "powershell.exe", "csc.exe") and
      _arraysearch(process.thread.Ext.call_stack, $entry, $entry.protection_provenance : "conemuhk64.dll*")) and
 not _arraysearch(process.thread.Ext.call_stack, $entry,
                  $entry.symbol_info : ("?:\\program files (x86)\\steam\\gameoverlayrenderer64.dll*",
                                        "?:\\program files\\windowsapps\\microsoft.windbg*\\amd64\\dbgeng.dll!DebugCreateEx*",
                                        "*\\vsdebugeng.impl.dll!ImplDllCreateInstance*",
                                        "?:\\program files\\windowsapps\\dolbylaboratories.dolbyaccess_*\\dlls\\x64\\dolbyaudioprocessing.dll*",
                                        "?:\\program files\\windowsapps\\pythonsoftwarefoundation.python.*\\dlls\\sqlite3.dll!sqlite?_enable_shared_cache*",
                                        "?:\\windows\\systemapps\\microsoft.windows.contentdeliverymanager_*\\contentdeliverymanager.background.dll!*")) and
 not process.thread.Ext.call_stack_summary : ("ntdll.dll|kernelbase.dll|gdb.exe|kernel32.dll|ntdll.dll", "ntdll.dll|bcrypt.dll") and
 not _arraysearch(process.thread.Ext.call_stack_final_user_module.code_signature, $entry, $entry.trusted == true and
                  $entry.subject_name in ("Microsoft Windows Hardware Compatibility Publisher",
                                          "Microsoft Windows Software Compatibility Publisher",
                                          "Valve Corp."))
'''

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

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

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


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

[internal]
min_endpoint_version = "8.10.0"