Weaponizing Note-Taking: REF6598 & PHANTOMPULSE in Obsidian
Just caught the Elastic Security Labs report on REF6598, and it’s a fascinating shift in initial access vectors. We’ve seen IDEs abused before, but threat actors are now weaponizing Obsidian—that popular markdown-based note-taking app—to drop a new Windows RAT called PHANTOMPULSE.
The campaign is highly targeted, specifically going after individuals in finance and crypto. The mechanism? Malicious community plugins. Since Obsidian relies heavily on JavaScript for extensibility, it’s a ripe surface for abuse if a user slips up and installs a compromised addon.
From what I gather, PHANTOMPULSE isn't just a simple keylogger; it establishes full C2 channels. The tricky part for SOC teams is that Obsidian is a legitimate productivity tool, so simply flagging the executable isn't enough. We need to focus on the child processes and the plugin integrity.
I’ve whipped up a quick PowerShell snippet to audit recently modified plugin files in user directories, which might help catch persistence mechanisms:
Get-ChildItem -Path "$env:APPDATA\Obsidian" -Recurse -Filter "main.js" -ErrorAction SilentlyContinue |
Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-7) } |
Select-Object FullName, LastWriteTime, @{Name="SignatureStatus";Expression={(Get-AuthenticodeSignature $_.FullName).Status}}
Given the rise of these "productivity tool" supply chain attacks, how are you all handling extensibility security for non-standard applications like Obsidian or Notion? Are you blocking plugin installation entirely at the network level, or do you have a whitelist process?
We actually saw a similar attempt with VS Code extensions last year, but this Obsidian vector is scary because the user base tends to be very 'trust-first' regarding community plugins.
Regarding detection, we've had success monitoring for unsigned JS files executing within the sandbox context, but the real tell is usually the network connection. PHANTOMPULSE seems to beacon out to domains that don't match Obsidian's update infrastructure. I'd recommend adding KQL rules to watch for Obsidian.exe spawning cmd.exe or powershell.exe—standard note-taking apps shouldn't need a shell.
As a pentester, I love this technique. It's purely abusing the 'trusted tools' concept. Users expect their notes app to access local files to sync them, so when a RAT exfiltrates data, the firewall sees traffic from a signed, trusted binary path.
For sysadmins managing this, AppLocker or Software Restriction Policies are your best friends here. You can block untrusted code execution in the %APPDATA%\Obsidian\plugins directory unless the files are signed by a specific certificate. It breaks the 'install random plugin' workflow, but it stops the initial access cold.
This hits close to home. We run a heavy crypto research team, and Obsidian is their standard for knowledge management. Banning it isn't an option without a revolt.
We're moving toward a centralized plugin repository. Instead of letting devs pull from the community hub, we're vetting plugins and hosting them on an internal Git server. It creates a bottleneck, but it ensures we aren't pulling REF6598-style droppers. It’s essentially an internal 'app store' model. Anyone else tried this approach for developer tools?
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access