A new attack campaign abused Obsidian’s community plugin ecosystem, turning a trusted note-taking app into a cross-platform malware-delivery platform.
The operation used social engineering, synced vaults, and a weaponized Shell Commands plugin to trigger separate malware chains on Windows and macOS.
Security researchers say the campaign began with a fake venture capital persona that contacted victims on LinkedIn and moved the conversation to Telegram.
The attackers then lured targets into opening an Obsidian vault they controlled and persuading them to enable community plugin sync, which let malicious plugin settings execute on the victim’s device.
Windows Attack Chain
On Windows, the plugin triggered a staged PowerShell chain that fetched a loader, decrypted an embedded payload, and executed it in memory.
The loader used AES-256-CBC, timer-queue callback execution, dynamic API resolution, and reflective loading to avoid writing the final malware to disk.
Researchers named the final implant PHANTOMPULSE, describing it as a full-featured RAT with injection, screenshot, keylogging, privilege escalation, and uninstall capabilities.
macOS Attack Chain
The macOS path used a different playbook. The Shell Commands plugin executed a Base64-encoded command that launched an obfuscated AppleScript dropper, created a LaunchAgent for persistence, and then fetched the next stage through a layered C2 process.
If the primary server was unavailable, the macOS dropper could fall back to a Telegram-based dead drop to recover a backup domain.
.webp)
That design made blocking a single domain less effective, since the malware could switch to another source for its next command or payload.
The important detail is that the attackers did not need to exploit a software bug in Obsidian itself.
Instead, they abused a legitimate feature: community plugins that are meant to run custom commands, combined with user-driven sync settings that allowed the malicious configuration to appear on the victim’s machine.
.webp)
The campaign also showed how a trusted, signed application can become the parent process for malicious activity, thereby weakening simple allowlist-based defenses.
In this case, the abuse of Obsidian’s normal behavior made the attack look like ordinary app activity until the command execution started.
According to Elastic research, defenders should watch for unusual child processes launched by Obsidian, especially PowerShell, osascript, curl, and other shell utilities.
They should also look for new or modified files under the .obsidian/plugins/ path, unexpected community plugin sync changes, and outbound traffic to unfamiliar domains or blockchain-related resolution services.
The most practical mitigation is to restrict or review the use of community plugins, especially in managed environments.
Since the attack relies heavily on user interaction and plugin configuration, policy controls, process monitoring, and network detections together give the best chance of stopping it early
Follow us on Google News , LinkedIn and X to Get More Instant Updates. Set Cyberpress as a Preferred Source in Google.
