The bait was a fake crypto conference. It wasn’t a real event, but the hacker made it look legit enough to get seasoned security researchers to click. That’s the surprise: a trusted Google Doc turned into a malware delivery platform right in the middle of Black Hat and DEF CON.
Key Takeaways
- The attacker pretended to represent a leading crypto news site and used X (formerly Twitter) to reach researchers.
- Google Docs, customized with Google App Script, displayed a fake encrypted sidebar to lure victims.
- Three payloads were offered: a macOS infostealer, a Windows remote‑desktop tool, and a bogus Ledger wallet installer.
- Huntress’ own researcher went along with the ploy to capture the malicious code.
- North‑Korean‑linked groups have a history of targeting security researchers, as shown by Google’s Threat Analysis Group and Ars Technica reports.
The Fake Crypto Conference Lure: How Google Docs Became a Weapon
On the week of Black Hat and DEF CON, a hacker slid into X DMs with a broken‑English pitch: “Are you going to the conference next? It’s organized by CryptoNews.io.” The message included a link to a Google Doc that looked like a planning spreadsheet. It even had a sidebar that claimed the file was encrypted. The attacker asked the target to type a “decryption key” right in the doc. That was the first step toward installing malware, according to Huntress.
It didn’t take long for the ploy to get noticed. Huntress published a blog post on Wednesday detailing how one of its researchers pretended to cooperate. The researcher let the hacker walk through the steps, capturing screenshots and the malicious scripts. That’s how we know the attacker used Google App Script to render the fake sidebar.
We’ve seen social engineering that cheapens a platform’s trust, but this was different. The document itself was clean; the malicious code lived in the script that ran when the victim entered the fake key. Once the key was submitted, the script fetched a payload tailored to the victim’s OS.
That’s the catch. The payloads weren’t generic. Huntress says the attacker tried to drop an infostealer for macOS, a remote‑desktop viewing tool repurposed as malware for Windows, and a fake installer that pretended to be the Ledger cryptocurrency wallet. Each was signed with a different file name to avoid basic heuristics.
Why Google Docs Made the Scam Believable
Google Docs is a staple in any developer’s workflow. It’s free, collaborative, and it integrates with Google App Script, which lets anyone add custom menus or sidebars. The hacker used that feature to make the document look like a secure briefing. The sidebar’s “encrypted” label gave the impression that the file contained sensitive information, which is exactly the kind of thing a researcher would expect when planning a conference.
Because the doc was hosted on Google’s domain, most email filters and endpoint tools whitelisted the traffic. That’s why the attack slipped past many defenses. It’s a reminder that trusted cloud services can be weaponized when attackers understand the UI.
North‑Korean Actors Have a Track Record of Targeting Researchers
Google’s Threat Analysis Group recently published a post that attributes a months‑long campaign to a North‑Korean‑backed group. The actors created a research blog, multiple X profiles, and even posted fake exploit videos. They’d previously used Visual Studio projects that bundled malicious DLLs, and they hosted malicious services on a blog at blog.br0vvnn.io. Those incidents show a pattern: the same nation‑state actors are comfortable hijacking legitimate developer tools to reach security pros.
Ars Technica reported a similar trend in 2023. Mandiant’s UNC2970 group—also tied to North Korea—started using fake LinkedIn recruiter accounts, then moved conversations to WhatsApp before delivering backdoors like Plankwalk via Word macros. The group’s malware families (Touchmove, Sideshow, Touchshift) were engineered to evade endpoint detection. Those campaigns, like the fake crypto conference lure, demonstrate a willingness to blend social engineering with custom code.
It isn’t coincidence that the same geopolitical actors are behind both the Google‑Doc scheme and the earlier UNC2970 operations. They both rely on the trust researchers place in community platforms—whether it’s a conference agenda, a blog post, or a LinkedIn recruiter.
Technical Walkthrough of the Google‑Doc Attack
- Step 1: Attacker contacts target on X, mentions a crypto‑news‑run conference.
- Step 2: Sends a Google Doc link that appears to be a planning sheet.
- Step 3: Doc includes a sidebar built with Google App Script that asks for a decryption key.
- Step 4: When the key is entered, the script fetches a payload from a C2 server.
- Step 5: Payload varies by OS: macOS infostealer, Windows remote‑desktop tool, or fake Ledger installer.
The script uses the Apps Script URLFetch service to pull the binary, then writes it to the user’s temporary folder. On macOS it runs the binary with chmod +x and launches it silently. On Windows it drops an executable that masquerades as a legitimate installer, then executes it via PowerShell. The malicious binaries communicate with a command‑and‑control domain that the researchers traced back to a hosting provider in Eastern Europe.
Historical Context: Malicious Use of Collaboration Platforms
Collaboration tools have long been a sweet spot for attackers. Early phishing campaigns often used shared network drives to slip malicious executables past perimeter filters. When cloud‑based suites entered the mainstream, the attack surface shifted from on‑prem file shares to web‑hosted documents.
Google’s own documentation describes how App Script can extend a doc’s functionality. That flexibility is why many internal tools rely on it for automation. The same openness that powers legitimate workflows also lets a determined adversary embed code that runs the moment a user interacts with a UI element.
Previous public analyses have highlighted how malicious actors masquerade as “review” or “approval” documents. Those cases typically involved a simple link that redirected to a malicious site. The current episode raises the bar by embedding the payload‑fetching logic directly inside the doc’s script environment. The result is a single click that pulls a binary without leaving the Google interface.
Security teams that have watched the evolution of document‑based attacks note a pattern: the lure becomes more context‑specific. A generic “invoice attached” email gave way to a “conference schedule” that matches the timing of major security events. The timing itself is a clue that the attacker is monitoring the community calendar and choosing moments when attention is split.
Understanding that trajectory helps defenders anticipate the next move. If a platform’s extensibility model is publicly documented, it will continue to be a vector. Mitigations must therefore focus on policy, not just signature‑based detection.
Real‑World Scenarios: How This Affects Different Roles
Below are three concrete situations that illustrate how the same technique can surface in everyday work.
- Scenario 1 – Conference Organizer. Maya runs a small crypto‑focused meetup. She receives a direct message on X from someone claiming to be a speaker. The message contains a Google Doc titled “Speaker Logistics.” Maya opens the doc to fill in travel details, clicks the custom sidebar, and unknowingly triggers a Windows payload that creates a remote‑desktop backdoor. Within minutes the attacker gains visibility into her laptop, where she stores speaker contracts.
- Scenario 2 – Vulnerability Researcher. Leo spends his mornings reviewing disclosed bugs on a shared Google Sheet that his team uses to track CVEs. An unfamiliar colleague shares a new sheet titled “Q4 Crypto Conference Draft.” The sheet looks identical to his usual template, but a hidden script asks for a decryption key. Leo types the key out of habit, and a macOS infostealer lands in his home directory, siphoning API keys from his local environment.
- Scenario 3 – Startup Engineer. A fintech startup adopts Google Workspace for its entire engineering org. The security lead enforces two‑factor authentication but allows all App Script features. A junior engineer receives a link to a “Ledger Wallet Integration Guide.” The doc’s sidebar prompts for a key, and a fake Ledger installer is dropped. The installer appears signed, so the engineer runs it, giving the attacker a foothold on a machine that holds testnet private keys.
Each story shares a common thread: a trusted document, a familiar workflow, and a script that runs behind the scenes. The damage isn’t limited to the initial machine; lateral movement can follow once a foothold is established.
What This Means For You
If you’re a security researcher or a developer who frequently collaborates on conference planning, you need to treat any unsolicited Google Doc with suspicion, even if it looks like it’s from a known source. Verify the sender’s email address, check the document’s sharing settings, and never paste a decryption key into a custom sidebar without confirming its authenticity.
For teams that build internal tooling, consider disabling or restricting Google App Script execution on corporate accounts. At the very least, enforce a policy that any script‑enabled document must be reviewed by a security gate before being opened. It’s a small step, but it could stop a malicious payload before it ever reaches a developer’s machine.
Key Questions Remaining
- How can organizations balance the convenience of App Script with the risk of script‑driven attacks?
- What automated signals could surface a malicious sidebar before a user interacts with it?
- Will cloud providers introduce stricter sandboxing for scripts that request external URLs?
- How will threat‑intel sharing evolve to flag newly minted C2 domains that appear in App Script payloads?
- What role does community education play when the attack vector lives inside a platform many consider “safe”?
Looking Ahead: The Blurring Line Between Trust and Threat
As cloud‑based collaboration tools become more feature‑rich, attackers will keep finding ways to weaponize those features. The fake crypto conference episode shows that even a platform as ubiquitous as Google Docs can be turned into a delivery vector when social engineering is layered on top.
Will future security‑researcher outreach programs incorporate automated verification of document scripts, or will they rely on manual checks that slow down collaboration? The answer will shape how the community balances speed with safety.
“We’ve seen a rise in campaigns that blend legitimate developer tools with social engineering, and this is a prime example,” said a Huntress researcher who chose to remain anonymous.
For more details, see the original report.
Sources: TechCrunch, Google Threat Analysis Group, Ars Technica
Primary sources: blog.google (Primary source linked by the report), arstechnica.com (Primary source linked by the report).
