Hook
Most security teams assume multi-factor authentication is the silver bullet. It’s the line in the sand: password compromised? MFA stops them. Session token stolen? MFA doesn’t even enter the picture. That’s the gap. And that’s exactly how a sequence of fake coding tests led to $11.8 million in losses across Singapore-based crypto projects. The attack wasn’t a zero-day in a smart contract. It wasn’t a flash loan exploit. It was a supply chain infiltration through the human layer—targeting developers during job interviews. Session tokens, not private keys, were the payload. And once the attacker had them, MFA was irrelevant.
Context
Singapore’s regulatory authorities disclosed the incident in late 2025: a coordinated recruitment scam that infected developers’ machines with malware during a fake coding challenge. The malware exfiltrated session tokens from the victim’s browser cache. The attacker then used those tokens to authenticate into the target project’s code repository—bypassing any MFA the developer had enabled. The final goal was not to steal code, but to access deployment keys, admin credentials, and possibly private keys stored in CI/CD pipelines. $11.8 million in confirmed losses. The attack chain is mature: fake job offer → coding test with malicious payload → session token theft → access to codebase. It’s a textbook example of spear-phishing, upgraded to the hiring process.
This is not a new attack vector per se—social engineering has been around for decades. But the precision targeting of Web3 developers, the reliance on session tokens, and the amount stolen signal a shift. Attackers are no longer betting on buggy smart contracts. They are betting on the fact that remote hiring processes are full of trust assumptions that have never been pressure-tested.
Core
Let’s dig into the technical chain because the details reveal why this is more dangerous than a typical phishing campaign.
Step 1: The Fake Coding Test
Attackers posed as a legitimate Web3 project (often using a well-known name or a hard-to-verify startup). They reached out to developers on LinkedIn or Telegram with a high-paying, remote role. The ‘coding test’ was a custom environment that required the candidate to run a set of scripts—often a Node.js or Python package with a hidden payload. The payload was a memory-resident trojan that avoided detection by traditional antivirus. It was designed to stay dormant until the developer accessed their browser session to check messages or authenticate into GitHub/GitLab.
Step 2: Session Token Exfiltration
Once the trojan was active, it hooked into the browser’s process to read session cookies and tokens. Most modern web applications, including GitHub, GitLab, and cloud consoles, issue a session token after login. This token is stored in the browser’s cookie store or local storage. The malware scanned for tokens associated with known code hosting platforms and exfiltrated them to a C2 server. The key insight: session tokens are not encrypted by default and are often valid for hours or days. Even if the developer used MFA, the token was obtained after the MFA challenge was already complete.
Step 3: Bypassing MFA
This is the critical point. Multi-factor authentication protects the login step, not the subsequent session. Once the token is stolen, the attacker can replay it directly via API calls or by injecting it into their own browser. No MFA prompt is triggered. The server sees a valid token from the same user agent—it’s indistinguishable from the legitimate session. This is a well-known weakness, but it’s rarely exploited in such a targeted manner. As I noted during my 2025 audit of a cross-chain bridge, the session token was the weakest link in the security chain—we recommended token binding to device fingerprints and short TTLs. Most projects didn’t implement it.
Step 4: Code Repository Access
With the token, the attacker logged into the project’s GitHub/GitLab account. From there, they could browse repositories, read secrets, and—if the developer had admin privileges—push malicious code, modify CI/CD pipelines, or extract private keys stored in GitHub Actions secrets. The $11.8 million loss likely came from direct asset theft using keys obtained from the codebase. This is consistent with the pattern: attackers don’t steal code; they steal the means to move funds.
Why Web3 projects are especially vulnerable
- Remote-first culture: Developers are used to joining teams via online tests. Trust is high, verification is low.
- Privilege bloat: Many developers have direct commit access to main branches, and even access to production secrets because “it’s faster.”
- Lack of isolation: Coding tests are run on the developer’s personal machine, which often has access to work credentials through browser sync.
- Token longevity: Sessions are kept alive for days, especially with “remember me” features.
This is exactly the kind of edge case I warned about in my 2020 Uniswap V2 audit—the assumption that the human layer is secure. Tracing the gas leak in the untested edge case of recruitment processes: the leak is not in the smart contract, but in the trust we place in a remote coding challenge.
Contrarian
Most security post-mortems will focus on the need for stronger MFA. But the real lesson is more uncomfortable: MFA is a placebo against session token theft. The industry has spent years convincing itself that “if we have MFA, we’re safe.” This event proves that the opposite is true. The attack didn’t target the login; it targeted the session. The only robust defense is hardware-bound tokens (FIDO2/Passkeys) that are bound to the device and cannot be exfiltrated as a string. But even that is not foolproof if the attacker gains full control of the machine.
Additionally, the narrative that “code audits protect assets” is flawed. Audits look at contracts, not at the human infrastructure. The code is a hypothesis waiting to break—and the hypothesis here is that the hiring process is safe. It’s not. We are seeing a shift from technical exploits to operational exploits. The biggest blind spot is the privilege escalation through hiring. Attackers are not trying to hack the protocol; they are trying to hack the developer. And once they do, they own the protocol.
Takeaway
The $11.8 million is not the end. It’s the beginning of a wave of recruitment-based attacks. The industry needs to adopt zero-trust hiring: isolate coding tests in disposable VMs, enforce session token binding to device fingerprints, and use hardware security keys tied to FIDO2 for all code repository access. Latency is the tax we pay for decentralization, but security lapses are the tax we pay for ignoring the human layer. When your codebase is only as secure as the next developer’s browser session, you’re already compromised. The question is: will you trace the leak before it’s too late, or after the next $11.8M disappears?