31000+ screenshots. 700+ zip files. All stolen from users who thought they were solving a CAPTCHA.
This is not a speculative threat model. It is the proven output of the StopAndProtect ransomware campaign, as documented by Check Point Research. The attack chain is simple, scalable, and devastatingly effective against cryptocurrency holders who store wallet recovery phrases on their devices.
Context: The Infrastructure Betrayal
StopAndProtect is not a novel ransomware family. It is a repurposed variant of the Chaos ransomware, but its distribution vector is what makes it relevant to the crypto ecosystem. The attackers compromised nearly 2,000 WordPress websites—likely through outdated plugins or weak credentials—and turned them into command-and-control (C2) nodes. These sites served as the initial delivery mechanism, hosting malicious payloads, storing stolen data, and issuing commands to infected machines.
The attack began in May 2024 and remained active as of July 24, targeting over 6,000 unique IP addresses. The geographic distribution of victims is predictable: the United States, Russia, and India lead the list. But the target is not geography—it is any Windows user who trusts a CAPTCHA.
Core: The Fake CAPTCHA and the PowerShell Trap
The attack unfolds in four stages:
- Compromise: The attacker exploits a WordPress vulnerability to gain control of the site. They inject a malicious script that replaces the legitimate CAPTCHA widget with a fake one.
- Lure: A visitor to the compromised site is presented with a CAPTCHA challenge. The instruction reads: "Press Win + R, then Ctrl + V, then Enter." This is a classic social engineering trick—the user is actually being told to open a Run dialog, paste a PowerShell command, and execute it.
- Execution: The PowerShell command downloads and executes the StopAndProtect ransomware from a remote server. The malware immediately begins encrypting files and, critically, stealing credentials and cryptocurrency wallet recovery phrases. It also spreads via network shares and USB drives.
- Exfiltration and Ransom: The malware takes screenshots of the victim's desktop (31,000+ captured) and compresses stolen data (700+ zip files). The attacker then demands a ransom in cryptocurrency for decryption and threatens to leak the stolen data.
The forensic detail that matters: The attackers specifically target recovery phrases. The malware scans for files containing common seed phrase patterns (12 or 24 words) and wallet-related directories. This is not random data theft—it is a surgical extraction of the keys to a user's crypto assets.
Why this attack works
Based on my experience auditing crypto security protocols, the attack exploits three fundamental weaknesses:
- User trust in visual cues: A CAPTCHA is a universal symbol of security. Users have been trained to solve them to prove they are human. The attackers hijack that trust to execute arbitrary code.
- The Windows PowerShell loophole: The command
powershell -WindowStyle Hidden -Command ...runs silently in the background. The average user has no reason to suspect that a simple key combination can lead to a full system compromise. - The opacity of recovery phrases: Most users store their seed phrases in plain text files, screenshots, or even in cloud-synced folders. The malware scans for these with regex patterns. Even if the user has a hardware wallet, if they ever typed the recovery phrase into a software wallet or browser extension on that machine, the phrase is recoverable from disk or memory.
The scale of the data breach is staggering. The researchers recovered 31,000+ screenshots, indicating that the attackers had a persistent view of victims' activities. The 700+ zip files likely contain entire desktop environments, including browser cookies, password manager exports, and wallet files. The attackers now have a detailed map of each victim's digital life.
Contrarian: What the Bulls Got Right
To be fair to the optimistic narrative: this attack is not a zero-day exploit. It relies on user ignorance and outdated WordPress sites. The technology itself—blockchain—is not broken. The attack does not exploit a smart contract vulnerability or a consensus flaw. It is a classic social engineering attack dressed in modern malware.
Moreover, the attackers are not sophisticated. They reused a known ransomware variant (Chaos) and relied on common WordPress vulnerabilities. The attack chain is well understood by security professionals. The fact that it succeeded at scale says more about the lack of basic security hygiene in the crypto user base than about any inherent weakness in the technology.
But here is the blind spot: The industry's narrative around "self-custody" and "not your keys, not your coins" places the entire burden of security on the user. No protocol-level protection exists for a user who willingly types their seed phrase into a compromised machine. The attack exposes a gap in the crypto ecosystem: there is no standard, user-friendly way to handle recovery phrases that is both secure and convenient. Hardware wallets are better, but they still require the user to enter the seed phrase during setup—a window of vulnerability.
Takeaway: The Ledger Does Not Forgive
This campaign is a wake-up call, but not for the reasons the hype machine will claim. It is not a failure of blockchain technology. It is a failure of operational security. The attack vector is not a smart contract bug—it is a human being following instructions on a screen.
As a forensic investigator, I see the same pattern repeated: users who trust the web interface of a compromised site, who execute unknown commands, who store their seed phrases in plain text. The attackers are not geniuses. They are opportunists exploiting the most predictable behavior in the ecosystem.
Hype evaporates; receipts remain. The 31,000+ screenshots and 700+ zip files are the receipts. The question is whether the industry will respond with better education and better tools, or whether it will wait for the next wave of phishing to steal the next set of keys.
Code is law. Victims are irrelevant. The blockchain does not care how the keys were lost. The transaction is final. The only way to prevent this is to understand that the weakest link in the chain is not the protocol—it is the user's next click.