
TL;DR
- Attackers impersonate OpenClaw via GitHub Discussion emails, offering 5,000 $CLAW tokens to "verified contributors"
- The link directs to token-claw.xyz, a pixel-perfect clone of the real OpenClaw homepage
- Clicking "Connect Wallet" loads a 10 MB obfuscated JavaScript file (
eleven.js) containing wallet-draining malware - The script bundles ethers.js with malicious
approve,permit, andeth_signcalls to silently drain tokens - Anti-debugging techniques —
debuggertraps, console hijacking, andsetIntervalloops — prevent inspection in Chrome DevTools
The Bait: A GitHub Discussion You Didn't Ask For
It starts with a GitHub notification that looks entirely legitimate. A bot account named ClawsBot-34236 posts a Discussion in giganodefinish/ClawChain-0499856, tagging dozens of real GitHub usernames:

The message hits all the right notes for a social engineering attack:
- Urgency: "Allocation: 5000 $CLAW" — a specific, enticing number
- Authority: "We evaluated profiles and shortlisted developers to access OpenClaw distribution"
- Pre-approval: "Wallets are already pre-approved" — reducing friction to act
- Credibility: Lists 30+ real GitHub usernames as "Verified Contributors" to create social proof
The call-to-action links to a Google Sheets URL, which redirects to the attack domain.
The Trap: A Cloned Homepage
The redirect lands on token-claw.xyz — a near-perfect replica of the real OpenClaw website. Same logo, same tagline ("THE AI THAT ACTUALLY DOES THINGS"), same testimonials carousel, same color scheme (see the hero image at the top of this article).
The only meaningful addition is a prominent "Connect Wallet" button with a "NEW" badge, positioned as the primary action. Everything else exists to build trust.
Clicking that button opens a standard WalletConnect modal listing MetaMask, Trust Wallet, OKX Wallet, and Bybit Wallet — all real wallet providers, rendered using real WalletConnect SDKs:

This is where the malware takes over.
The Payload: Deconstructing eleven.js
Once a wallet connects, the page loads eleven.js — a 10.4 MB, 11,859-line obfuscated JavaScript file. Rather than trying to read it manually (which is exactly what the attacker designed against), I analyzed it programmatically.
File Profile
| Metric | Value |
|---|---|
| File size | 10,457 KB |
| Lines of code | 11,859 |
| Hex literals | 383,666 |
Obfuscated variable prefixes (a0*) |
84 unique |
| Switch statements (control flow flattening) | 215 |
| Encoding functions (atob, btoa, escape, etc.) | 41 |
Obfuscation Stack
The script uses JavaScript Obfuscator with aggressive settings. Four layers of obfuscation make manual analysis impractical:
1. String Array with Rotation
All meaningful strings are extracted into a massive array function (a0f) containing thousands of encoded fragments. A decoder function (a0g) maps hex offsets to array indices:
function a0g(a, b) {
const c = a0f();
a0g = function(d, e) {
d = d - 0xb7;
return c[d];
};
return a0g(a, b);
}An IIFE then rotates the array at startup, meaning static analysis of the array contents yields gibberish without executing the rotation first.
2. Control Flow Flattening
With 215 switch statements, the script's logical flow is shattered into state machines. Instead of sequential if/else blocks, each function's logic is scattered across switch cases that execute in a non-obvious order — determined at runtime by obfuscated state variables.
3. Hex-Encoded Property Access
Every property access and method call is routed through the decoder. Instead of window.ethereum, the code reads something like:
k[a2M(0x35c2a) + '...']With 383,666 hex literals in the file, reverse-engineering any single function requires decoding hundreds of lookups.
4. Self-Defending Code
The script includes self-defending patterns that detect tampering. If the code's toString() representation changes (from beautifying or editing), it alters its behavior — crashing or producing wrong results instead of executing the real payload.
Anti-Debugging Arsenal
The script actively fights inspection:
| Technique | Count | Purpose |
|---|---|---|
debugger statements |
5 | Pauses execution when DevTools is open |
setInterval calls |
4 | Continuous debugger-detection loops |
console[...] bracket access |
125 | Hijacks/overrides console methods |
Function() constructor |
2 | Dynamic code generation to evade static analysis |
The setInterval-based debugger detection is particularly nasty — it runs on a timer, repeatedly checking whether DevTools is open by measuring execution time of debugger statements. If detection triggers, the script either halts or enters a decoy path.
The 125 console bracket accesses suggest the script overwrites console.log, console.warn, and console.error with no-ops or redirects, preventing developers from logging what the script does even if they manage to inject monitoring code.
The Wallet Drainer
Here's what the malware is actually built to do. Pattern analysis reveals a comprehensive Web3 attack toolkit:
| Pattern | References | Attack Vector |
|---|---|---|
wallet |
356 | Wallet detection and connection |
connect |
292 | Automated wallet connection |
token |
295 | Token enumeration and targeting |
chain |
496 | Multi-chain support |
network |
317 | Network switching |
RPC |
263 | Direct RPC calls to bypass wallet UI |
sign |
174 | Transaction signing |
transaction |
145 | Transaction crafting |
provider |
124 | Provider injection/hijacking |
contract |
75 | Smart contract interaction |
balance |
62 | Balance checking |
abi |
255 | ABI encoding for contract calls |
approve |
22 | Token approval (unlimited spend) |
permit |
9 | Gasless approval via EIP-2612 |
eth_sign |
4 | Raw message signing |
WalletConnect |
9 | WalletConnect protocol |
MetaMask |
4 | MetaMask-specific targeting |
ERC20 |
3 | ERC-20 token standard |
allowance |
5 | Approval state checking |
WebSocket |
6 | Persistent connections |
The decoded string fragments tell the story even more clearly. The code contains references to:
EIP712Domain,verifyingContract,signature— EIP-712 typed data signing, used to trick wallets into signing what appears to be a benign message but is actually a token approvalSigningKey,computePublicKey,recoverPublicKey— Key manipulation functions from ethers.jsdefaultAbiCoder,TransactionDescription,errorSignature— Full ABI encoding stack for crafting arbitrary contract callsgetContractAddress,stateMutability— Contract introspection to dynamically target tokens
Attack Sequence (Reconstructed)
Based on the reference patterns, the likely attack flow is:
- Connect: Wallet connects via WalletConnect or MetaMask injection (292
connect+ 9WalletConnectrefs) - Enumerate: Script queries balances across multiple chains (62
balance+ 496chainrefs) - Approve: Requests unlimited token approvals via
approveor gaslesspermitsignatures (22 + 9 refs) - Sign: Uses
eth_signor EIP-712 typed data to get the victim to authorize transfers that look like harmless interactions (174sign+ 4eth_signrefs) - Drain: Executes
transferFromon approved tokens to the attacker's address (145transactionrefs)
The permit pattern (9 references) is especially dangerous — it allows gasless approvals via EIP-2612, meaning the victim pays no gas for the approval transaction and may not even see a transaction in their wallet history.
Red Flags That Should Have Stopped You
If you received this email, here's what should have raised alarms:
- The domain:
token-claw.xyzis not an official OpenClaw domain - The Discussion repo:
giganodefinish/ClawChain-0499856is a throwaway repository with no real code - Google Sheets redirect: Legitimate token distributions don't route through Google Sheets
- "Wallets are already pre-approved": No legitimate airdrop pre-approves wallets — this phrase exists purely to reduce skepticism
- Mass @-mentions: Tagging 30+ users in a single Discussion is a shotgun approach, not a targeted distribution
- The script size: A 10 MB JavaScript file for a "Connect Wallet" button is absurd — legitimate dApps load 100-500 KB
How to Protect Yourself
If you connected your wallet:
- Immediately revoke all token approvals using Revoke.cash or Etherscan Token Approval Checker
- Move remaining funds to a new wallet — the compromised wallet's private key was not exposed, but any signed approvals remain active
- Check transaction history for unauthorized
approveorpermitcalls
Going forward:
- Never connect your wallet to a site from an unsolicited email or GitHub notification
- Verify domains independently — type them manually or use official bookmarks
- Use a dedicated burner wallet for testing new dApps
- Install browser extensions like Wallet Guard that warn about known phishing domains
- If an airdrop sounds too good to be true, it is
The Bigger Pattern
This attack exploits a specific trust chain: GitHub notifications carry implicit authority for developers. We trust them because they come from our professional platform. Attackers weaponize that trust by creating Discussions in obscure repos, tagging real users, and riding GitHub's own email infrastructure to deliver phishing links.
The obfuscation level of eleven.js — 383,666 hex literals, 215 switch statements, anti-debugger traps — shows this is not amateur work. This is a professional wallet drainer toolkit repackaged with an OpenClaw-themed frontend. The Web3 security community has tracked similar drainers across hundreds of phishing campaigns.
The defense is boring but effective: verify domains, use burner wallets, and never let urgency override caution. A free airdrop that requires your wallet approval is never free.