Hook
$11.8 million. That’s the confirmed loss from a single social engineering campaign targeting Singapore-based Web3 projects. The attack vector? A fake coding test. Not a smart contract exploit. Not a flash loan attack. A job interview.
Context
Singapore’s authorities recently disclosed a coordinated series of phishing attacks where attackers posed as legitimate recruiters. They invited developers to complete a “coding challenge” — a standard practice in Web3 remote hiring. The challenge contained malware that hijacked session tokens from the victim’s browser. Once inside the code repository, the attackers bypassed MFA entirely and drained assets. The total tally: $11.8 million and counting.
This isn’t a new vulnerability. It’s a proven, repeatable workflow that weaponizes the one thing most protocols ignore: the human trust layer.
Core: The Session Token Kill Chain
Let me break down the mechanics because the market is pricing this as a “one-off phishing event.” It’s not. It’s a blueprint.
- Malware in the coding environment – The attacker delivers a payload disguised as a Node.js or Python starter script. The victim runs it locally. The malware extracts browser cookies, localStorage, and most importantly, session tokens for GitHub, GitLab, or internal CI/CD dashboards.
- MFA is irrelevant – Session tokens are temporary credentials issued after MFA. If you steal the token, you don’t need to pass the second factor again. This is basic session management, yet most Web3 teams still rely on OTP-based MFA.
- Code repository access – With a valid token, the attacker can clone repos, read deployment keys, and in some cases, push malicious commits. The $11.8M loss likely came from stolen private keys stored in repo configs, environment variables, or a
.envfile that was never meant to be committed.
I’ve seen this pattern before. In 2022, during the Terra collapse, I audited a Curve pool that had admin keys stored in a plain-text config file. The team didn’t even use a hardware wallet for the deployer address. This is the same negligence, scaled.
Contrarian: The Real Vulnerability Isn’t Code — It’s Process
Every security report I read focuses on smart contract audits, formal verification, and bug bounties. Those are necessary. But they miss the biggest open door: the hiring pipeline.
Web3 projects are desperate for talent. They onboard remote developers through LinkedIn, Telegram, and Discord. They trust a resume and a GitHub profile. They send a coding test without an isolated sandbox. They grant repository access before the candidate has signed an NDA. This is the equivalent of handing a stranger the keys to the vault because they passed a phone screen.
Let me be blunt: if you’re a project with a multisig or a deployer key, and you allow any developer to run arbitrary code on their local machine as part of “testing,” you are one fake job offer away from losing everything.
In DeFi, liquidity is the only truth that matters. But here, the liquidity being drained is trust. And once trust breaks, the entire protocol becomes illiquid.
Takeaway: Actionable Levels
Expect this attack vector to proliferate over the next 3–6 months. The barriers to entry are low: a fake LinkedIn profile, a cloned coding challenge, and a few hundred dollars for a malware kit. The ROI is absurd.
If you’re a project lead, do these three things TODAY:
- Enforce hardware-backed MFA (FIDO2/Passkeys) for all repository access. OTP is dead. Treat every session token as a bearer asset — it can be stolen, and when it is, you lose everything.
- Sandbox every coding test. Use disposable VMs or remote containers (e.g., GitHub Codespaces with read-only access). Never let a candidate run a binary on your team’s hardware.
- Audit your repo permissions. If any developer has write access to a branch that contains private keys or deployment scripts, you have a ticking bomb.
Greed is a variable; discipline is the constant. The $11.8M loss is a tuition fee. Learn from it before your project becomes the next headline.