How a Fake Crypto Conference Lure Turned Google Docs Into a Malware Delivery Tool

The campaign combined a familiar professional setting with trusted online services. An account on X, @HartmansDoeke, claimed to represent CoinDesk and approached people associated with Black Hat and DEF CON, sometimes through public replies before moving the conversation into direct messages. The attacker then proposed a supposedly CoinDesk-organized cryptocurrency conference and shared a Google Doc presented as planning material. 1411

The important distinction is that the Google document itself could look legitimate. The malicious behavior came from an embedded Google Apps Script interface and the instructions delivered through it. The supplied reporting describes an attempted malware delivery chain; it does not establish that the Huntress researcher or other targets installed the payload. 468

How the social-engineering approach worked

The opening messages used the conference context as a credibility shortcut. The impersonator asked, in broken English, whether the researcher planned to attend another event and then introduced a fictitious conference connected to a well-known crypto news outlet. Public replies helped identify or approach likely attendees, while DMs created a private channel for the next steps. 4510

Once the target showed interest, the actor sent a document that appeared to be a conference-planning file. The document was paired with an “encryption” or decryption key supplied in the X conversation. This made the exchange feel like ordinary event coordination rather than a conventional phishing attempt. 68

The Google Docs and Apps Script trap

An authenticated Google user opening the file saw a custom sidebar alongside the document. Huntress described the sidebar as an interface that made the material appear partially encrypted and prompted the recipient to enter the supplied key. The key appeared to fail, creating a reason for the target to follow the sidebar’s suggested recovery steps. 68

Those follow-on options included ClickFix-style instructions and a download path. Both were intended to persuade the recipient to download and execute malicious code. In other words, the document was not merely a link to a suspicious external page: legitimate Google hosting and a native-looking Docs interface were used to make the workflow feel familiar. 48

That trust signal is the campaign’s central lesson. A real google.com URL or a document that opens inside a known productivity service can confirm where content is hosted, but it does not prove that the document, script, instructions, or downloads are safe.

Malware reported in the campaign

The reported delivery paths differed by operating system:

• macOS: The campaign sought to deliver Atomic macOS Stealer, or AMOS, an infostealer. Reporting also links the macOS path to a fraudulent Dropbox DocSend share and a counterfeit installer. 2
• Windows: The operation involved NetSupport RAT, a legitimate remote-support and remote-desktop product repurposed as a remote-access trojan. 2
• Cryptocurrency targets: Researchers also identified a counterfeit Ledger wallet installer or implant, suggesting that cryptocurrency credentials and wallet-related information were among the apparent objectives. 2

The available evidence describes intended payloads and delivery mechanisms, not a confirmed compromise of the researcher who investigated the campaign.

How Huntress investigated the lure

The targeted Huntress researcher recognized the approach as suspicious but continued the conversation while pretending to cooperate. That allowed Huntress to observe the actor’s messages, receive the document, and document how the fake encryption prompt led toward malware execution. The researcher did not install the payload. 1411

This method produced unusually useful visibility into the attack chain. Instead of stopping at the first suspicious message, the investigation connected the X identity claim, the conference pretext, the Google Doc, the Apps Script sidebar, the fake key prompt, and the operating-system-specific malware paths.

What security teams should take from it

The campaign shows why conference-related outreach deserves the same scrutiny as email phishing, even when it arrives through a public social platform and uses a legitimate cloud service.

Practical warning signs include:

• an unsolicited approach from an account claiming to represent a conference organizer, media company, or sponsor;
• a request to move from a public reply into DMs before the person’s identity has been independently verified;
• a document that asks for a key, password, or “decryption” step supplied in a separate chat;
• a Google Doc that uses a custom sidebar or unusual interactive prompt to direct the recipient to download software or paste commands; and
• a wallet, remote-support tool, or conference utility offered outside the organization’s independently confirmed channels.

If someone followed the instructions, the safest response is to isolate the affected system, reset potentially exposed credentials, rotate secrets, and review cryptocurrency wallets and other sensitive accounts. 1819

What the supplied reporting does—and does not—confirm

The reporting supports the core mechanics: impersonation on X, public replies and DMs, a fake crypto-conference pretext, a Google Doc enhanced with Apps Script, a supplied fake decryption key, ClickFix-style follow-on instructions, and attempted delivery of malware affecting macOS and Windows. 1246811

The supplied record does not provide a verified statement from the suspected attacker or Google. It also does not contain enough evidence for a specific comparison with named government-linked campaigns. At a broad level, the incident fits a familiar pattern of tailored social engineering against security professionals, while its notable variation is the use of trusted Google-hosted content and an Apps Script interface as part of the delivery flow.