Phantom in the vault: Obsidian abused to deliver PhantomPulse RAT

Summary

Elastic Security Labs uncovered a new social engineering campaign that abuses the Obsidian note-taking platform and its community plugin ecosystem to deliver PhantomPulse, a previously undocumented RAT targeting both Windows and macOS systems. The operation appears aimed at individuals in the financial and cryptocurrency space, with attackers using LinkedIn and Telegram to distribute a compromised Obsidian vault as the initial lure. On Windows, the infection chain relies on PowerShell, a custom in-memory loader known as PhantomPull, and reflective loading techniques. On macOS, the attackers use AppleScript along with a Telegram-based dead-drop command-and-control mechanism. The campaign also incorporates blockchain-based C2 discovery through Ethereum transaction data.

Investigation

Researchers reproduced the attack by building a weaponized Obsidian vault that used the Shell Commands and Hider plugins to trigger malicious execution. During analysis, they observed PowerShell scripts downloading a loader named syncobs.exe from 195.3.222.251, which then retrieved an encrypted payload and loaded it reflectively in memory. The loader created a mutex, communicated with a control panel hosted at panel.fefea22134.net, and supported fallback infrastructure derived from blockchain data. On macOS, the malware established persistence through a LaunchAgent plist and downloaded a secondary AppleScript payload from a hard-coded domain and a Telegram channel. Investigators recovered key artifacts from JSON configuration files and in-memory resources tied to both infection paths.

Mitigation

Organizations should prevent Obsidian from spawning unauthorized child processes, apply strict controls over community plugin usage, and monitor for PowerShell activity where Obsidian appears as the parent process. Network defenses should block outbound traffic to 195.3.222.251 and the domains panel.fefea22134.net, 0x666.info, and known Telegram dead-drop locations associated with the campaign. Security teams should also look for signs of reflective loading, timer-queue callback abuse, and the specific mutex value used by the malware loader.

Response

If suspicious child processes are detected from Obsidian, isolate the affected host immediately and collect the .obsidian directory for forensic review of malicious plugin files and vault content. Hunt for the mutex hVNBUORXNiFLhYYh, then scan endpoints for traces of the PHANTOMPULL loader and PHANTOMPULSE RAT binaries. Block the identified command-and-control infrastructure, revoke any compromised Obsidian-related credentials, and perform a broader review for credential theft exposure involving financial and cryptocurrency accounts.

Simulation Execution

Prerequisite: The Telemetry & Baseline Pre‑flight Check must have passed.

Rationale: This section details the precise execution of the adversary technique (TTP) designed to trigger the detection rule. The commands and narrative MUST directly reflect the TTPs identified and aim to generate the exact telemetry expected by the detection logic. Abstract or unrelated examples will lead to misdiagnosis.

• Attack Narrative & Commands:

  1. Initial Compromise: The attacker drops a malicious Obsidian plugin (evil-plugin.js) into the user’s Obsidian plugin directory.
  2. Execution Trigger: When Obsidian starts, the plugin runs a PowerShell one‑liner that launches notepad.exe via Start-Process. This creates the exact Obsidian.exe → notepad.exe process chain the rule watches.
  3. Persistence: The plugin is set to autoload on every Obsidian launch, ensuring the malicious child process recurs.
  4. Evasion: The plugin also briefly invokes rundll32.exe (T1216.002) to load a benign DLL, masking the true intent while keeping the detection‑triggering chain intact.

• Regression Test Script:

  # -------------------------------------------------
  # Malicious Obsidian plugin simulation (PowerShell)
  # -------------------------------------------------
  # 1. Ensure Obsidian is installed at the expected path
  $obsidianPath = "C:Program FilesObsidianObsidian.exe"
  if (-Not (Test-Path $obsidianPath)) {
      Write-Error "Obsidian not found at $obsidianPath"
      exit 1
  }
  
  # 2. Launch Obsidian *as the parent* and immediately spawn Notepad
  $startInfo = New-Object System.Diagnostics.ProcessStartInfo
  $startInfo.FileName = $obsidianPath
  $startInfo.Arguments = "-c `"Start-Process notepad.exe`""
  $startInfo.UseShellExecute = $false
  $startInfo.CreateNoWindow = $true
  
  $proc = [System.Diagnostics.Process]::Start($startInfo)
  
  # 3. Optional: invoke a signed binary (rundll32) to simulate T1216.002
  Start-Process -FilePath "C:WindowsSystem32rundll32.exe" -ArgumentList "shell32.dll,Control_RunDLL" -WindowStyle Hidden
  
  # 4. Keep the script alive briefly to allow logs to be emitted
  Start-Sleep -Seconds 5
  # -------------------------------------------------

• Cleanup Commands:

  # Terminate any stray Obsidian or Notepad instances created by the test
  Get-Process -Name "Obsidian","notepad","rundll32" -ErrorAction SilentlyContinue | Stop-Process -Force
  
  # Remove the simulated malicious plugin file (if it existed)
  $pluginPath = "$env:APPDATAObsidianpluginsevil-plugin.js"
  if (Test-Path $pluginPath) { Remove-Item $pluginPath -Force }
  
  Write-Host "Cleanup complete."