On April 14, 2026, Elastic Security Labs published an analysis of a social engineering campaign it tracks as REF6598. The operation uses Obsidian, the note-taking application with millions of users, as an initial access vector for a cross-platform remote access trojan that Elastic named PHANTOMPULSE. There is no CVE, no zero-day, no compromised update channel. The Obsidian binary itself is clean and signed. What the attackers weaponized was the application’s design.
The mechanism is simple on paper. A threat actor impersonating a venture capital firm contacts a target on LinkedIn, moves them into a Telegram group stacked with fake partners for credibility, and hands them credentials to a shared Obsidian cloud vault framed as the firm’s “management database.” Once the victim logs in and enables community plugin sync (a setting off by default and not propagated between devices automatically), a preconfigured Shell Commands plugin silently executes arbitrary code on vault open. On Windows the chain lands a reflective in-memory loader and a 64-bit RAT that resolves its command and control infrastructure through Ethereum transaction data. On macOS it drops a persistent LaunchAgent and fetches its next stage from a Telegram dead drop. Elastic Defend caught the intrusion early and blocked it before PHANTOMPULSE fully deployed.
The reason REF6598 is worth studying is not the RAT, though PHANTOMPULSE is novel on several dimensions. The reason is what the attack exploits. Obsidian is the flagship example of a local-first, extensible, sovereignty-preserving desktop tool, the kind of product power users recommend precisely because it does not sandbox them. The REF6598 operators did not find a hole in that model. They used it as designed.
The attack chain, with receipts
The Shell Commands plugin, authored by the developer Taitava, is exactly what it sounds like. It executes platform-specific shell commands on configurable triggers: Obsidian startup, vault close, timed intervals, custom hotkeys. It is a power-user tool with a legitimate audience. When the victim in REF6598 opened the attacker’s vault, a file at .obsidian/plugins/obsidian-shellcommands/data.json contained a startup command with two Base64-encoded PowerShell Invoke-Expression calls. Decoded, they fetched a second-stage script from a Polish hosting provider (AS 201814, MEVSPACE) at 195.3.222.251 and executed it with a hidden window and bypassed execution policy.
Stage two used BitsTransfer to pull down a 64-bit PE named syncobs.exe, which Elastic calls the PHANTOMPULL loader. PHANTOMPULL is a PE that extracts an AES-256-CBC-encrypted payload from its own resources (the key is hardcoded in .rdata, the IV on the stack), decrypts it, and reflectively loads it via a timer queue callback. That payload then fetches the final stage, PHANTOMPULSE, from panel.fefea22134.net over HTTPS, decrypts it with a 16-byte rotating XOR key, parses it as a DLL, and calls DllRegisterServer to hand off execution.
PHANTOMPULSE itself is a full-featured Windows RAT. It keylogs, captures screenshots, does process injection via module stomping, escalates privileges through a COM elevation moniker, and runs a command dispatcher that hashes incoming commands with the djb2 algorithm and routes them through a switch statement. The Elastic team documented strong indicators of AI-assisted development in the binary: unusually verbose, self-documenting debug strings using structured step-numbering patterns like [STEP 1/3], and a C2 admin panel branded “Phantom Panel” whose visual design also carries AI generation fingerprints.
The most technically interesting element is the C2 resolution. PHANTOMPULSE queries three Blockscout instances (Ethereum L1, Base L2, Optimism L2) for the most recent transaction associated with a hardcoded wallet, 0xc117688c530b660e15085bF3A2B664117d8672aA. It strips the 0x prefix from the transaction input data, hex-decodes, and XOR-decrypts the result using the wallet address as the key. If the decoded output starts with http, it becomes the new active C2 URL. Publishing a new endpoint requires only submitting a transaction with crafted calldata to the wallet on any of the three monitored chains. Blockchain transactions are immutable and publicly accessible, so centralized takedown is ineffective. Elastic also identified a weakness: the malware does not verify the transaction’s sender, so anyone who knows the wallet address and the XOR key (both recoverable from the binary) can submit an inbound transaction with a sinkhole URL and hijack every live implant. Elastic flagged this as a C2 takeover opportunity for responders.
None of this involves a software vulnerability. Every step uses documented Obsidian behavior. The Shell Commands plugin works exactly as advertised. The vault sync works exactly as advertised. The community plugin sync boundary, which must be manually crossed by the victim, works exactly as advertised. Pairing it with the Hider plugin (authored by kepano, Obsidian’s designer) was the elegant touch. Hider is a UI cleanup plugin, and the attackers turned every concealment option on to suppress status bars, scrollbars, tooltips, and sidebar buttons. The victim saw a calm, clean interface while a PowerShell reverse shell negotiated with a Polish host in the background.
Obsidian’s own docs admit this is unfixable
Obsidian’s plugin security documentation is unusually honest about the threat model. The vendor states plainly that community plugins run third-party code, and that “due to technical limitations, Obsidian cannot reliably restrict plugins to specific permissions or access levels.” Community plugins inherit Obsidian’s full access level. They can read files on the user’s computer. They can connect to the internet. They can install additional programs. Obsidian’s only structural defense is Restricted Mode, which blocks community plugins by default, and a review process that runs on initial plugin submission but does not re-audit every update across thousands of plugins maintained by volunteers.
This is the price of the local-first design. Obsidian does not sandbox plugins because doing so would break the plugin model. A real sandbox requires a permission system, and a permission system requires the core team to adjudicate what every plugin can and cannot do. That is a different product. It is closer to how VS Code is heading with its workspace trust model, closer to how Chrome extensions are constrained under Manifest V3, closer to how mobile app stores work. Those products exist. Users who want Obsidian’s ergonomics chose Obsidian precisely because it does not behave that way.
REF6598 is the first public demonstration of what happens when that tradeoff meets a motivated adversary willing to run targeted social engineering at the level of a bespoke intrusion set. The attack chain does not require a zero-day, a supply chain compromise, or even a malicious binary on disk. It requires convincing one target to enable one setting and log into one vault. That is the attack surface of every extensible desktop tool that treats plugins as first-class code.
The pattern beyond Obsidian
The attack generalizes. Replace Obsidian with Logseq, Remnote, Joplin, Raycast, or any Electron application with a community plugin ecosystem. The specifics of Shell Commands matter less than the architectural fact that a user-controllable configuration file can trigger code execution on trusted startup events. Elastic’s framing of the detection problem matters here: the payload lives entirely inside JSON configuration files that are unlikely to match traditional antivirus signatures, and execution is handed off by a signed Electron application, which breaks parent-process-based detection unless defenders specifically watch for knowledge-work desktop apps spawning shell interpreters.
The cross-story context is where REF6598 fits into a pattern that has been visible in this archive for weeks. The Axios npm compromise in March used a hijacked maintainer account to push a RAT to a library with 100 million weekly downloads. North Korea’s Contagious Interview operation expanded the same technique across five package ecosystems simultaneously, reaching 1,700 tracked packages. The ToolHijacker paper at NDSS 2026 showed that prompt injection can hijack the tool selection layer of LLM agents 96.7 percent of the time, and every published defense tested failed. The OpenClaw architecture analysis documented 1,184 malicious skills in the marketplace and 104 CVEs rooted in design decisions that cannot be patched. The Langflow RCE at CVE-2026-33017 was exploited within 20 hours with no public proof of concept.
REF6598 is the same story one layer closer to the end user. The class of attack is trust-model exploitation against extensible platforms. Package registries, AI agent tool catalogs, agent skill marketplaces, MCP servers, and now productivity plugins all live in the same topology: user-installable third-party code, minimal vendor review at update time, no sandboxing primitive that would meaningfully constrain post-install behavior, and adversaries who have figured out that social engineering is the cheapest initial access vector on the menu.
What Elastic did not test and what the report leaves open
The attack is not fully automatic, and the Elastic writeup is explicit that this matters. A secondary machine connecting to the same synced vault receives the base configuration files but not the community plugins directory or the community-plugins.json manifest. Those are local client-side toggles that do not propagate through sync by default. The victim must manually enable community plugin sync for the weaponized plugin configuration to flow through. That toggle is the social engineering moat, and it held until the attackers convinced the target to disable it.
Elastic also did not fully analyze the macOS chain. The C2 infrastructure for the AppleScript dropper was already offline at analysis time, which means the payload ultimately delivered to macOS victims is unknown. The Windows chain is documented because the Windows infrastructure was still live. Anyone reasoning about total campaign impact needs to treat the macOS side as a partial story.
The writeup does not cover Obsidian’s business response. There is no confirmation yet that Obsidian plans to change default behavior for plugins that perform shell execution, to require additional prompts on vault open when previously unseen plugins are enabled, or to harden the community plugin sync boundary with explicit attestation. The vendor’s plugin security page was written before REF6598 and reflects the existing posture. One possibility is that Obsidian adds friction at the sync boundary. Another is that the team argues, reasonably, that the social engineering step cannot be defeated by product design and that Restricted Mode plus user education is the correct architectural answer.
Attribution is also incomplete. Elastic named the intrusion set REF6598 but did not attribute it to a known threat actor group. The infrastructure overlaps (Polish hosting, Cloudflare tunnels as a prior C2 endpoint, a funded Ethereum wallet with roughly fifty transactions from a related address) provide pivot points but no firm identification. Anyone reading this as a nation-state story is reading ahead of the evidence.
What happens next
Two things are worth watching. First, whether the technique spreads. REF6598’s tradecraft is cheap to replicate. A Shell Commands configuration plus a Hider plugin to suppress UI elements plus a compelling business cover is not an expensive operation. The financial and cryptocurrency targeting in this campaign reflects where irreversible value lives today, but the pattern will travel to legal, M&A, research, compliance, and any team that shares knowledge bases across organizational boundaries. Elastic has published YARA rules and hunting queries, and the indicator set includes the staging server at 195.3.222.251, the C2 panel at panel.fefea22134.net, the mutex hVNBUORXNiFLhYYh, the macOS dropper domain 0x666.info, and the Telegram fallback channel at t.me/ax03bot. Defenders with Obsidian in their environments should add the KQL detection query Elastic published, which looks for processes named Obsidian or Obsidian.exe writing to paths containing obsidian-shellcommands, or spawning child processes like sh, bash, zsh, powershell.exe, or cmd.exe.
Second, whether the Obsidian community accepts that the plugin model as it exists creates an attacker-reachable code execution channel for any user who can be socially engineered. The architectural response would be something like VS Code’s workspace trust model: a strong, friction-heavy prompt when a vault wants to run third-party code, with defaults that require explicit per-vault attestation. That imposes cost on power users. It also changes what Obsidian is. The vendor’s existing stance, stated on its security page, is that plugin security is fundamentally a user-trust problem that the application cannot solve with permission controls. REF6598 is the strongest public counterexample to that stance to date.
The deeper signal is that adversaries have identified a class. AI-assisted malware, visible here in the verbose debug strings and the AI-generated admin panel, paired with extensible sovereign productivity tools, is a new attack topology. It is cheaper to build than a supply chain compromise. It is harder to detect than a signed malicious binary. It resists centralized takedown because the C2 resolution sits on public blockchains. ToolHijacker, the OpenClaw skill marketplace, the npm and PyPI operations, and now REF6598 all point in the same direction. Trust models that rely on user vigilance are a solvable security problem only if vendors are willing to change what their products are.
Obsidian has not said whether it will.