[New Rule] Command Interpreter Spawned by Obsidian

[Aryu-RU]

Issue link(s)

None yet — opening with a detailed summary per the PR template. Happy to file a New rule issue first if the team prefers that flow.

Summary - What I changed

Adds one new cross-platform EQL detection rule under rules/cross-platform/, Command Interpreter Spawned by Obsidian, which fires when the Obsidian note-taking application spawns a command or script interpreter. To keep the signal-to-noise high on hosts that legitimately run community plugins, the strongly-anomalous and documented interpreters fire directly, while the more commonly-benign shells are gated behind download/execution arguments:

• Windows: Obsidian.exe → powershell.exe / pwsh.exe (the documented PhantomPulse vector — matched directly); or cmd.exe when its command line shows download/execution behavior.
• macOS: Obsidian → osascript (the documented AppleScript vector — matched directly); or sh / bash / zsh when the command line shows download/decode behavior.

Why this is a real threat. Obsidian does not natively execute shell commands; the only common way it spawns an interpreter is through a community plugin — most notably Shell Commands (obsidian-shellcommands), which can be configured to auto-run commands when a vault opens. Elastic Security Labs' Phantom in the Vault (REF6598) documents an active campaign where a victim is socially engineered into logging into an attacker-controlled Obsidian Sync vault and enabling community-plugin sync, which delivers a weaponized data.json that launches a PowerShell download cradle (iwr ... → Start-BitsTransfer ...) on vault open, ultimately delivering the PhantomPulse RAT. The article notes: "An Elastic Defend behavior alert triggered on suspicious PowerShell execution with Obsidian as the parent process." This rule generalizes that exact observed behavior into a durable parent→interpreter detection across Windows and macOS.

Coverage gap (deduplicated against the current ruleset). No existing rule covers Obsidian as a parent:

• rules/windows/initial_access_suspicious_execution_from_vscode_extension.toml — structurally similar but hardcodes node.exe/Code.exe + .vscode/extensions; does not fire for Obsidian.
• rules/windows/defense_evasion_communication_apps_suspicious_child_process.toml — fixed communication-app parent list (Obsidian absent), Windows-only.
• rules/windows/execution_windows_powershell_susp_args.toml — may opportunistically catch the Windows download stage but provides no Obsidian attribution and no macOS coverage.

Obsidian currently appears in the repository only as a benign allowlist entry (rules/windows/command_and_control_common_webservices.toml, which governs Obsidian's own outbound plugin-fetch traffic) — never as a detection subject, so this rule is complementary, not overlapping.

This follows the accepted "trusted application as interpreter parent" pattern already in the repo — e.g. rules/windows/defense_evasion_suspicious_zoom_child_process.toml (Zoom.exe → cmd/powershell) and rules/windows/initial_access_suspicious_execution_from_vscode_extension.toml — applied to a parent (Obsidian) that has no existing coverage.

How To Test

Representative matching event (Windows), mirroring the documented chain:

{
  "event": { "type": ["start"], "category": ["process"] },
  "host": { "os": { "type": "windows" } },
  "process": {
    "name": "powershell.exe",
    "command_line": "powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -File \"%TEMP%\\tt.ps1\"",
    "parent": { "name": "Obsidian.exe" }
  }
}

macOS equivalent: process.parent.name: "Obsidian" spawning osascript / sh / bash / zsh.

Local validation on this branch:

• python -m detection_rules validate-rule rules/cross-platform/execution_command_interpreter_spawned_by_obsidian.toml → successful
• python -m detection_rules validate-all → Rule validation successful
• pytest tests/test_all_rules.py → 51 passed, 1 skipped

MITRE ATT&CK

• T1059 Command and Scripting Interpreter — .001 PowerShell, .002 AppleScript, .003 Windows Command Shell, .004 Unix Shell
• T1204.002 User Execution: Malicious File
• Tactic: Execution (TA0002)

References

• https://www.elastic.co/security-labs/phantom-in-the-vault
• https://github.com/Taitava/obsidian-shellcommands

False positives

• The Shell Commands plugin used legitimately causes Obsidian to spawn an interpreter as designed — documented in false_positives with guidance to review the plugin's data.json and add exceptions for trusted users/hosts.
• Other plugins that shell out (e.g. the Git plugin invoking git) can spawn cmd or a Unix shell — review the child command line.

The rule is medium severity / risk_score 47, consistent with the accepted VS Code-extension analogue, reflecting behavior with a legitimate-but-uncommon path.

Reviewer considerations

• Scoped to Elastic Defend victim-host process telemetry (logs-endpoint.events.process-*), which actually emits this event.
• The malicious data.json is delivered via Obsidian Sync (written by Obsidian itself) and Shell Commands is a legitimate plugin, so a file-write detector on data.json would be high-FP; the data.json path is included as an investigation-guide triage step instead of a detection condition.

Checklist

• Added the Rule: New label for the type of PR
• Secret and sensitive material has been managed correctly
• (CI) RTA / automated testing — can add an RTA emulation if desired
• Documentation and comments were added for features that require explanation (investigation guide)

Contributor checklist

• Contributor License Agreement signed
• Followed the contributor guidelines

[Aryu-RU]

Quick summary for triage: this rule detects Obsidian spawning a command/script interpreter — the execution behavior from the PhantomPulse campaign documented in Elastic Security Labs' Phantom in the Vault (which notes a Defend behavior alert fired on PowerShell with Obsidian as the parent). No existing rule anchors on Obsidian as a parent; PowerShell/pwsh/osascript fire directly, while cmd and Unix shells are gated behind download/execution arguments to keep false positives low on hosts running the legitimate Shell Commands or Git plugins.

Happy to adjust scope, add an RTA, or tweak the MITRE mapping based on your feedback.