The Obsidian RAT Attack Is a Warning About Every App That Runs Untrusted Plugins
One malicious Obsidian plugin deployed a full remote access trojan — and the same door is open everywhere.
You Installed a Plugin. You Handed Over Your Computer.
Think about the last time you installed a browser extension or a VS Code plugin. You probably skimmed the name, checked that the install count looked reasonable, and clicked install. What you almost certainly did not do is read the source code. Neither did most of the people who just got hit by the Obsidian PHANTOMPULSE campaign. Here is what actually happened: attackers posed as a venture capital firm and targeted financial and cryptocurrency professionals. They engaged victims on LinkedIn, then moved conversations to Telegram group chats with multiple fake "partners" to build credibility. Victims were told to use Obsidian as the firm's "management database" and were given credentials to an attacker-controlled cloud vault, framed as a shared dashboard. Once the vault was opened and community plugin sync was enabled — a setting that is off by default — a malicious configuration for Obsidian's Shell Commands plugin silently synced into the victim's environment and executed without any further user interaction on the next trigger. Elastic Security Labs, which identified and named this campaign REF6598, first spotted it when telemetry flagged suspicious PowerShell spawned directly from the legitimate Obsidian binary. That detail matters: nothing about the Obsidian installation itself was tampered with. The attack lived entirely inside the plugin layer.
How the Attack Actually Worked: The Mechanism Explained
The Shell Commands plugin is a legitimate, community-built Obsidian plugin that lets you run terminal commands triggered by vault events — things like "run this script when the vault opens." Attackers configured it to execute Base64-encoded PowerShell on vault open. That PowerShell downloaded a second-stage script from a remote server, which then fetched a loader binary called syncobs.exe — named PHANTOMPULL — and reported execution status back to the same command-and-control infrastructure. PHANTOMPULL is a 64-bit Windows loader that decrypts an embedded AES-256-CBC encrypted payload from its own resources and reflectively loads it into memory, then retrieves the PHANTOMPULSE RAT over HTTPS. A cosmetic "Hider" plugin was also synced into the vault to conceal UI elements and reduce the victim's suspicion. The key design choice that makes this so effective: the core payload is kept inside JSON configuration files and memory-only loaders. There is no obvious malicious executable sitting on disk for antivirus to find. Elastic noted this approach makes traditional signature-based and file-centric defenses far less effective. Everything appeared to be a clean, legitimate Obsidian installation. --- **🔍 Jargon-Free Explainer: Key Terms** - **RAT (Remote Access Trojan):** Malware that gives an attacker live, remote control of your machine — like someone else having a copy of your keyboard and screen. - **Reflective loading:** Running a program directly in memory without writing it to disk first, making it much harder for security tools to detect. - **C2 (Command-and-Control):** The attacker's server that sends instructions to infected machines and receives stolen data. - **AES-256-CBC:** A strong encryption standard — here used by attackers to hide their payload inside an otherwise innocent-looking file.
Why the Plugin Model Is Structurally the Same Problem Everywhere
The Obsidian attack is not a one-off. It is a demonstration of a structural property that every plugin-based application shares: community-built code runs with the same permissions as the host application, and most plugin marketplaces have review processes that are closer to theatre than gatekeeping. VS Code is the clearest parallel. ReversingLabs researchers identified 19 malicious extensions on the VS Code Marketplace hiding malware inside dependency folders — malicious files disguised as PNG images, abusing legitimate npm packages to avoid detection. Trend Micro documented the Evelyn Stealer campaign, where weaponized VS Code extensions deployed a multistage information stealer that harvested browser credentials through DLL injection, captured screenshots, stole cryptocurrency wallet data, and communicated with a C2 server over FTP. The GlassWorm campaign went further: at least 72 malicious extensions were found in the Open VSX registry since January 2026, using extension dependency relationships to turn initially innocent-looking packages into delivery vehicles after trust had already been established — the malicious payload only arrived in a later update, after the extension had been installed and trusted. The 7AI-documented "Claude Fraud" campaign showed the same attack surface exploited via a trojanized VS Code extension masquerading as a Claude Code plugin, with over 15,600 victims documented publicly. In one case, the Checkmarx security toolchain itself was compromised — attackers swapped existing trusted versions of the KICS Docker container and VS Code extensions with malicious versions carrying credential-stealing payloads, meaning developers who expected to run an already-trusted version received a malicious one instead.
Where the Risk Is Highest: A Practical Mental Model
Not all plugins carry equal risk. The attack surface varies by how much trust the host application grants by default and how rigorous the review process actually is. The Obsidian model is particularly exposed because community plugins are off by default but trivially enabled, cloud vault sync can propagate plugin configurations across machines without per-plugin confirmation, and the Shell Commands plugin — a legitimate tool — provides direct OS-level execution capability with no additional permission prompt. VS Code extensions run in a Node.js environment with broad filesystem and network access; the marketplace review process has repeatedly failed to catch malicious extensions before they accumulated significant install counts. When evaluating whether a plugin is worth its attack surface, four signals are worth checking: **Maintainer reputation** — is this a named individual or organisation with a verifiable track record, or an account created last month? **Permission scope** — does a markdown formatting plugin need network access? If yes, that is a red flag. **Install count trajectory** — a plugin that jumped from 200 to 50,000 installs in two weeks deserves more scrutiny than one that grew steadily over two years. **Last commit date** — abandoned plugins with no recent maintenance are prime candidates for account takeover and malicious update injection, the exact mechanism GlassWorm exploited. The Hacker News weekly recap that surfaced this story noted the broader pattern concisely: "It's not breaking systems — it's bending trust." Slower check-ins, multi-stage payloads, code kept in memory, attackers leaning on real tools and normal workflows. The plugin ecosystem is purpose-built for exactly this.
What Should Change — and What to Watch Next
The Obsidian attack reveals a specific gap: enabling community plugin sync should require explicit per-plugin confirmation, not a single toggle. The Shell Commands plugin's ability to execute arbitrary OS commands on vault events is a legitimate power-user feature that has no business being silently propagated via a shared cloud vault from an untrusted source. VS Code's extension model gets one thing meaningfully right that others do not: Microsoft has invested in extension signing and publisher verification infrastructure, though as the repeated GlassWorm and Evelyn campaigns demonstrate, this is necessary but not sufficient. What the VS Code Marketplace still lacks is runtime permission scoping — the ability to declare and enforce that a linting extension cannot make outbound network calls. The Microsoft Security Blog's guidance on the OpenClaw agent runtime offers a useful framing that applies equally here: treat any environment that can ingest untrusted code and execute it with your credentials as untrusted code execution with persistent credentials. That mental model — not "is this plugin popular?" but "what can this plugin do with my credentials?" — is the right starting point. **What to watch:** The GlassWorm campaign's use of extension dependency chains to deliver payloads in later updates is the technique most likely to scale. A plugin that is clean on install day can become malicious after a single dependency update. Supply chain monitoring tools that track extension behaviour over time, not just at install, are the next meaningful defensive layer. Watch whether Obsidian introduces per-plugin permission declarations — and whether VS Code's marketplace begins requiring runtime capability disclosure as a publishing condition.
Sources
- [1]⚡ Weekly Recap: Vercel Hack, Push Fraud, QEMU Abused, New Android RATs Emerge & More — The Hacker News
- [2]Hackers Exploit Obsidian Plugin to Deploy Cross-Platform Malware — gbhackers.com
- [3]VS Code extensions contain trojan-laden fake image | RL Blog — ReversingLabs
- [4]Running OpenClaw safely: identity, isolation, and runtime risk — Microsoft
- [5]From Extension to Infection: An In-Depth Analysis of the Evelyn Stealer Campaign Targeting Software Developers — www.trendmicro.com
- [6]Malicious Microsoft VSCode AI extensions might have hit over 1.5 million users — TechRadar
- [7]Claude Code vs GitHub Copilot: Better Together? — wiz.io
- [8]Claude Fraud - When Trusted Tools Become the Attack Surface: Weaponizing AI Developer Tooling Against the Security Community — 7AI
- [9]GlassWorm Supply-Chain Attack Abuses 72 Open VSX Extensions to Target Developers — The Hacker News
- [10]Checkmarx suffers second massive supply chain attack, infecting developers with malware — Cybernews
- [11]Real time identification of phishing attacks through machine learning enhanced browser extensions — Nature
Comments
No comments yet — be the first to weigh in.