Threat actors have found a clever way to abuse a trusted productivity tool to deliver malware.
By weaponizing Obsidian’s Shell Commands community plugin, attackers are quietly executing malicious code on victims’ machines — all without exploiting a single software vulnerability.
The campaign, tracked as REF6598, targets individuals working in the financial and cryptocurrency sectors.
The attack begins with a carefully staged social engineering scheme. Threat actors pose as representatives of a venture capital firm and reach out to victims through LinkedIn.
Once a target responds, the conversation moves to a Telegram group where multiple fake partners join to make the exchange seem more credible.
Victims are then directed to use Obsidian — presented as the firm’s internal management database — and are handed credentials to connect to a cloud-hosted vault that the attacker fully controls.
Elastic Security Labs researchers identified the campaign after an Elastic Defend behavior alert triggered on suspicious PowerShell execution with Obsidian as the parent process.
Researchers Salim Bitam, Samir Bousseaden, and Daniel Stepanic traced the activity directly to Obsidian itself, ruling out third-party DLL sideloading or JavaScript injection.
The team confirmed that the Shell Commands plugin — installed inside the malicious vault — was configured to execute attacker-defined shell commands the moment the vault was opened, requiring no additional interaction from the victim.
Execution chain diagram (Source – Elastic)
The campaign targets both Windows and macOS systems. On Windows, the attack chain leads to the deployment of a previously undocumented RAT named PHANTOMPULSE — a full-featured backdoor capable of keylogging, screenshot capture, process injection, and privilege escalation.
On macOS, the attack uses an obfuscated AppleScript dropper combined with a Telegram-based fallback mechanism for command-and-control (C2) communication.
Process visualization with Elastic XDR (Source – Elastic)
Both paths were designed to hide behind normal application behavior, significantly raising the bar for traditional detection methods.
From Vault Sync to Final Payload
Once the victim opens the attacker-controlled vault and enables community plugin sync, the trojanized Shell Commands plugin’s data.json configuration file downloads silently and triggers execution.
On Windows, the plugin fires two Invoke-Expression calls with Base64-encoded strings, reaching out to a staging server at 195.3.222[.]251 to retrieve a PowerShell script.
This script then uses BitsTransfer to download a 64-bit executable called syncobs.exe and reports each step back to the C2 using color-coded status messages such as “GREEN FILE FOUND ON PC” and “RED DOWNLOAD ERROR.”
Data.json content of the shell plugin (Source – Elastic)
The downloaded executable — dubbed PHANTOMPULL by researchers — decrypts an AES-256-CBC-encrypted payload from within its own resources and loads it entirely into memory using reflective loading.
The malware never writes its final stage to disk, making it far harder to detect through conventional file-based scanning. PHANTOMPULL also employs a timer queue callback with a 50-millisecond delay to hand off execution, a tactic used to slip past sandbox environments.
Additionally, the loader includes dead code blocks and a fake integrity check function that serve no operational purpose beyond wasting an analyst’s time during reverse engineering.
Execution flow via Stage 1 (Source – Elastic)
PHANTOMPULSE — the final deployed RAT — uses a novel C2 resolution technique built around public Ethereum blockchain data.
The malware queries Blockscout APIs across three blockchain networks, reading XOR-encrypted C2 URLs from the input fields of transactions tied to a hardcoded wallet address.
Researchers noted a significant design flaw in this mechanism: because PHANTOMPULSE always selects the most recent transaction without verifying who sent it, any party who extracts the wallet address and XOR key from the binary can submit a competing transaction to redirect all infected hosts to a sinkhole server.
Organizations in the financial and cryptocurrency sectors should monitor for unusual child process creation from Electron-based applications like Obsidian.
Behavioral endpoint detection tools should be enabled, and community plugin installation policies should be enforced where possible.
Security teams are advised to hunt for file events matching obsidian-shellcommands paths and block known infrastructure including 195.3.222[.]251 and panel.fefea22134[.]net.
Elastic’s published YARA rules for PHANTOMPULL and PHANTOMPULSE offer a practical starting point for detection across environments.
Follow us on Google News, LinkedIn, and X to Get More Instant Updates, Set CSN as a Preferred Source in Google.
The post Hackers Weaponize Obsidian Shell Commands Plugin to Launch Cross-Platform Malware Attacks appeared first on Cyber Security News.
