On April 13, 2026, Eastern 8 Time, Elastic Security Labs disclosed a new type of social engineering attack specifically targeting professionals in the finance and cryptocurrency industries: hackers disguised themselves as venture capital institutions or business partners, accurately reaching out to targets through LinkedIn and Telegram, and then lured them into opening an Obsidian note library that contained malicious code. This attack chain did not rely on system-level "0-day vulnerabilities" but instead abused the Shell Commands plugin of Obsidian, silently delivering the PHANTOMPULSE remote control Trojan in the background, and using Ethereum blockchain transaction data to establish a "blockchain-based C2" communication channel. The traditional narrative of "fake websites and phishing links" has been thoroughly revamped—ordinary work communication and note-taking scenarios have evolved, under the combination of social engineering and on-chain technology, directly into an entry point for assets and commercial intelligence.

Fake VC Appears: From Adding Friends on LinkedIn to "Sending You Research Materials"

In the first half of the attack, the hackers played roles such as "VC partner," "research manager," or "strategic cooperation manager," first appearing in the victim's LinkedIn connection requests or Telegram friend invitations. Elastic Security Labs pointed out that the targets were locked in on financial institutions and cryptocurrency professionals: fund researchers, traders, project BD, human resources/operations, etc., who are highly sensitive to "funding, projects, and cooperation," and are prioritized for "adding on WeChat." The profile page features a professional avatar, seemingly reasonable work history, and some industry jargon, making it easy to break through the first psychological defense line of practitioners against unfamiliar accounts.

Once the initial trust is established, the plot seamlessly slides into familiar work scenarios— the other party throws out bait like "research materials," "sector analysis," and "internal investor BP," claiming, "We are recently looking in your direction; here’s a piece of our internal research for discussion." Subsequently, they may send a compressed file or cloud storage link, with file descriptions often stating, "Research materials for the Obsidian note library, to facilitate your continued recording and annotation." For practitioners already accustomed to using Obsidian or Notion for managing knowledge bases, "importing a ready-made note library" is nearly a natural operation.

The danger of the attack lies in the fact that the entire process hardly touches the traditional red line of "malicious links." Elastic's report found no signs of exploiting operating system or browser vulnerabilities, but was entirely based on the victim's trust in office collaboration scenarios and commonly used note-taking tools. Users manually download, manually import, and manually open, making it seem indistinguishable from their daily workflow, yet this silently completes a transition from social engagement to device control—a classic example of highly targeted social engineering + tool abuse.

Note-taking Software Becomes a Weapon: Plugins Are Hacked, Not the Software "Compromised"

To understand why this incident chose Obsidian, we must first revisit the ecosystem of this tool itself. As one of the mainstream knowledge management software, Obsidian is known for markdown local storage, cross-platform support, and a highly open plugin system. A vast array of community plugins allows it to expand from "note-taking" to "lightweight IDE, task flow driver, research workstation." Developers can use plugins to call local file systems, execute scripts, and trigger external programs—this degree of freedom in a "programmable workstation" is the reason it has become popular among programmers and researchers and is the fundamental reason it was chosen as the attack vector this time.

Elastic Security Labs and industry analysts indicated that the attackers did not breach the security boundaries of Obsidian software itself but targeted one legitimate plugin, Shell Commands. The normal capability of this plugin is to bind commands in notes to execute scripts or programs locally, facilitating users to automate the handling of files, build projects, or perform batch operations on data. In a Windows environment, the attackers disguised the malicious logic within the structure of the "imported note library," and through the preset configuration of Shell Commands, silently executed commands when the victim opened the related page or triggered specific actions, silently retrieving and launching the PHANTOMPULSE remote control Trojan. From a technical perspective, this is an abuse of the expected capabilities of a "code execution plugin," rather than an invasion of the Obsidian core.

Because of this, industry commentary has outright stated that this is "the first observed targeted attack utilizing note-taking software plugin mechanisms rather than vulnerabilities." Compared to traditional methods of delivering Trojans through browser vulnerabilities, Office macros, or PDF vulnerabilities, this model bypasses a large number of existing security strategies—antivirus software finds it challenging to simply categorize "executing scripts plugins" as malicious, and users have long been accustomed to running various automation scripts locally. If this incident is seen as a "proof of concept," its demonstration effect on ecosystem security far exceeds the act of a single attack.

It must be made clear that the source of risk does not lie in whether "Obsidian is secure" as a binary judgment, but rather in "how much authority programmable plugins have." The plugins abused in this incident were those that users actively installed, actively authorized, and which already possessed code execution capabilities. Blaming all responsibility on "Obsidian vulnerabilities" is both factually incorrect and could cause unnecessary panic—what truly needs reflection is how we set boundaries and usage habits for these high-permission plugins.

PHANTOMPULSE Lurking: Cross-Platform Remote Control Eyes on Your Daily Operations

When Shell Commands successfully delivered the malicious script on the Windows side, the stage center turned to a name that had not previously been widely exposed: PHANTOMPULSE. According to Elastic Security Labs and industry analysis, this is a new type of Windows remote control Trojan, which, once successfully deployed, establishes a long-term control channel on the victim's machine, capable of issuing commands, stealing information, and adjusting persistence methods as needed. Unlike traditional "fast in and out" ransomware or phishing, its positioning is closer to a "covert monitoring system," residing in the background with low visibility.

Intelligence provided by Elastic also indicates that this attack infrastructure is not limited to the Windows platform. In a macOS environment, attackers employed another attack chain: executing code via obfuscated AppleScript, while using Telegram as a backup C2 channel to maintain reachability of the victim's device across different platforms and network environments. This cross-platform design indicates that the attackers were not acting on a whim; rather, they have built a relatively mature multi-end control framework, with the Obsidian note library merely being one disclosed entry.

In conjunction with office and research scenarios, the greatest threat of such remote control Trojans lies not in "immediate theft of assets," but in long-term lurking and behavioral profiling. They can quietly observe: what devices you log into which exchanges, what type of wallet signatures you use, when you participate in large transfers, how teams discuss fundraising and strategy adjustments internally. For cryptocurrency professionals, asset security, trading strategy, and project information are often concentrated on the same machine and account system; as long as attackers have sufficient patience, waiting for a "suitable operational moment" can be far more rewarding and discreet than immediate theft.

On the defensive side, Elastic noted that its security product, Elastic Defend, has successfully blocked some attack samples, indicating that existing endpoint security solutions can still establish defenses at certain stages, such as identifying abnormal behavior, intercepting suspicious processes, etc. However, at the same time, as the attack chain evolves into "office tools + cross-platform remote control + blockchain communication," detection difficulty continues to rise. Traditional methods that rely on static features and known signatures find it hard to comprehensively cover threats deeply embedded in daily workflows.

Hacking the Ethereum Notepad: Blockchain Becomes C2 Dark Web

The most "cryptonative" aspect of this incident is the so-called "blockchain-based C2". According to a source, the attackers used Ethereum blockchain transaction data to hide remote control instructions or configuration parameters in the public ledger, which the Trojan reads to synchronize information with the control end. In other words, traditional C2 servers migrated from some hidden IP or domain to a public chain ledger that everyone can access but is difficult to "block."

Industry voices pointed out that "blockchain-based C2 communication significantly increases the difficulty of threat detection." The reason being: most security and compliance frameworks still rely on malicious domains, IP blacklists, and traffic characteristics to mark threats, while accessing Ethereum nodes and reading transaction data is often entirely normal networking behavior in many financial and cryptocurrency business contexts. In this model, malicious communications and normal business traffic overlap significantly, causing traditional detection baselines of "looking at IPs and domain names" to be nearly circumvented.

Treating the public blockchain as an "enemy intelligence mailbox" not only technically challenges existing defense models, but also brings new problems for compliance monitoring, on-chain analysis, and security companies: even if you block suspicious domains or server clusters, attackers can still hide within normal transactions on mainstream public chains. For regulatory bodies, how to identify abused on-chain communication models while protecting privacy and openness will become one of the future challenges.

It should be emphasized that many specific details surrounding this C2 model are still being validated. Currently available information has not confirmed specific Ethereum addresses or internal numbers, and research institutions are also deliberately avoiding disclosing unverified technical details to prevent misguiding the attention of the security community. For readers, it is more important to understand the model and path of using on-chain data as instruction carriers, rather than focusing on a specific address or transaction, creating the illusion of "cutting down a tree makes you think you've cleared the entire forest."

From Wallet to Workflow: How Cryptocurrency Professionals Are Being Gradually "Chased Down"

When placing this incident on a longer timeline, one discovers that the attackers have been continually advancing along the same main line: People → Social → Workflow. In earlier years, the most common threats were phishing websites, fake airdrops, and fake customer service, with attacks occurring at the browser and wallet plugin levels; subsequently, fake project parties and fake exchange employees directly "added friends" via social software, moving the attack entry point to social relationships themselves. Now, by fabricating VCs and partners, and further embedding malicious logic into daily office tools like Obsidian, it illustrates that the adversaries have profoundly understood: truly high-value actions often originate in meetings, documents, notes, and internal communications, rather than a singular "signing moment."

There are structural reasons why financial and cryptocurrency professionals have become primary targets:

● On one hand, this group has a very high asset density with frequent on-chain operations, whether managing their own funds or client assets and project funds, each of their signatures may correspond to large values; on the other hand, they are highly dependent on new tools and new cooperation relationships—they need to quickly trial various note-taking, collaboration, and automation tools, while needing to frequently connect with new investors, project parties, and service providers. Driven by "efficiency anxiety" and "information FOMO," it easily gives social engineering an opening.

● From the perspective of attack costs, while the combination of "cross-platform + plugins + blockchain C2" raises technical barriers, it also significantly enhances the reusability after a successful attack. Once a certain Obsidian note library + plugin configuration attack chain has been validated as effective, the same model can be replicated to more vertical industries, more collaborative tools, and more on-chain asset forms at extremely low marginal costs. For mature hacker organizations, this is more akin to a "critical infrastructure investment" rather than a single campaign.

Security products like Elastic Defend have demonstrated some protective effectiveness in this incident, but it also exposes a reality: single-point security products struggle to independently handle the trinity of "social engineering + tool abuse + on-chain covert communication". Social engineering belongs to the cognitive and process level, plugin abuse occurs within the office tool ecosystem, and blockchain C2 crosses traditional network boundaries—any one link failing leads to an overall defense being compromised. This compels both enterprises and individuals to upgrade from "installing an antivirus software" to a security outlook of strategy, process, tools, and habits evolving collaboratively.

The Next Wave of Attacks Is On the Way: What More Can We Do?

Faced with such an attack chain extending from social platforms, cross-platform remote control to on-chain C2, organizations and individuals cannot hope for "complete isolation." A more realistic approach is to proactively add "security barriers" in identity verification, tool permissions, and asset isolation. For organizations, it is crucial to establish strict external cooperation identity review mechanisms for positions involved in funding, transaction decisions, and core data: for contacts claiming to be from VC firms, law firms, audits, or project parties, introduce background checks and multi-channel verification to avoid integrating into internal processes based on "just a LinkedIn profile and a brief introduction."

Surrounding tools like Obsidian, organizations should develop plugin whitelists and permission tiering strategies for employees, limiting the usage of high-risk plugins like Shell Commands in production environments and requesting code audits or centralized management configuration when necessary. At the same time, independently secure policies and physical isolation should be configured for key asset operation devices (such as those responsible for signing, matching, and risk control): try not to carry out "asset signing + daily communications + experimental tool trials" all on the same machine.

For security teams, the incident disclosed by Elastic serves as a clear signal: on-chain data is systematically being used as C2 channels, detection and threat intelligence systems must be upgraded accordingly. Beyond existing domain and IP blacklists, attempts should begin at modeling "blockchain communication patterns" —including but not limited to abnormal access patterns, specific script and node interaction behavior analysis, rather than simply viewing all on-chain traffic as “whitelist business.” Establishing collaborative networks with on-chain analysis firms, security companies, and node service providers will be an important part of future defense architecture.

From a longer-term perspective, as blockchain's status within financial infrastructure continues to rise, it both carries asset settlement and clearing, and inevitably becomes a potential attack vector and covert communication medium. The industry must adapt to this dual property by establishing new safety consensus among "programmability, openness, and security controllability": tools should not be simply divided into "absolutely safe or not," but integrated within an observable, auditable, and responsive security framework under clear risk models. Attackers have already begun treating your notebooks as entry points and using Ethereum ledgers as dark webs; the defense side must genuinely extend "security" from wallets to entire workflows.

Join our community, let's discuss and become stronger together!
Official Telegram community: https://t.me/aicoincn
AiCoin Chinese Twitter: https://x.com/AiCoinzh

OKX Welfare Group: https://aicoin.com/link/chat?cid=l61eM4owQ
Binance Welfare Group: https://aicoin.com/link/chat?cid=ynr7d1P6Z

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。