Crypto Attackers Don’t Take Year-End Holidays

Christmas week has a predictable rhythm onchain: Fewer engineers awake, more retail activity, more “quick checks” on phones, more copying and pasting, more trust placed in familiar interfaces. That rhythm is a resource. Attackers don’t need new cryptography; they need timing, distribution, and small seams in how people ship code and move funds.

Chapter 1: The wallet that shipped itself a backdoor

It begins like most supply-chain incidents do: quietly, inside something users already trust.

A malicious release of the Trust Wallet Chrome extension (v2.68) was distributed, and users were later urged to move to v2.69. The malicious build wasn’t a clever “onchain hack.” It lived in the browser, where the private material is briefly usable, and where a wallet must sometimes handle mnemonics and decryption paths as part of normal function.

From there the logic is brutally direct. The backdoored extension code iterated through wallet data, prompted for mnemonic phrases, decrypted stored secrets after the user unlocked the wallet, and exfiltrated the mnemonic to attacker infrastructure (public reporting points to api.metrics-trustwallet[.]com). Once the attacker has the seed, the rest is automation: recreate wallet, sign valid transactions, drain assets at the pace of opportunity.

The publishing path matters as much as the payload. Reporting describes the malicious version as published outside the normal release flow, with signs that developer secrets and store publishing capability were abused (Chrome Web Store API key misuse and compromise of developer secrets have been discussed in incident coverage). That is the real failure mode: not “users clicked a link,” but “the update channel became the attacker’s channel.” The impact was reported in the $7M–$8.5M range with thousands of affected wallets.

In a holiday window, that’s the perfect crime: It scales, it’s fast, and every drained wallet looks “legitimate” onchain because it is.

Chapter 2: The New Year email that only needed one signature

As the calendar flips, the attacker switches from distribution to persuasion.

Investigators flagged a cluster of drains across EVM chains: hundreds of wallets, typically under $2,000 each, totaling over "07,000 at the time of reporting. Victims described an email framed as a mandatory MetaMask upgrade, wrapped in New Year branding.

The interesting part is what this doesn’t look like. A campaign that consistently takes small-to-medium amounts across many wallets often fits “approval drainer” economics more than “seed compromise” economics. With a seed, the attacker empties everything quickly. With approvals and signatures, the attacker relies on users being logged-in, signing what looks routine, and granting a spender contract the right to move tokens later.

So the likely flow is simple:

1. lure to a clone site,
2. prompt a “verification” that is really a signature or approval,
3. use that authorization to transfer tokens out, chain by chain, wallet by wallet.

It’s the quiet cousin of a full key theft. No malware needed, no exploit needed, just one convincing prompt when the user’s guard is down.

Chapter 3: The address that looked right in the transaction history

Then comes the kind of attack that feels almost unfair because it’s pure interface friction turned into loss.

Address poisoning doesn’t crack keys. It doesn’t exploit a contract. It exploits how humans verify strings.

A single incident dominated December’s loss totals: roughly $50M USDT lost to an address poisoning scam. The victim’s behavior reads like “best practice,” which is what makes it so effective: Withdraw from an exchange, send a small test transfer to confirm the destination, then send the real amount.

The attacker waits for the test. Then they send a dust transfer from an address engineered to resemble the true recipient (matching prefix and suffix characters), so it appears in the victim’s recent transaction list. When the victim later copies the address from history, they pick the poisoned entry and send the large transfer to the attacker.

No deception onchain, only deception in what the wallet UI makes easy.

Chapter 4: “Multisig” isn’t a shield when the keys are already gone

Holiday incidents also lean into a recurring theme: Teams and whales rely on multisigs, then discover the real boundary is the endpoint where signing happens.

A whale multisig reported as 0xde5f…e965 was drained for ~$27.3M, with ~4,100 ETH routed through Tornado Cash, and indications that remaining positions were still attacker-controlled. The initial classification was “private key compromise.”

Then the deeper forensic narrative surfaced: Analysis cited by coverage suggests total losses may exceed $40M, with indicators dating back to early November, and a striking detail: The multisig’s ownership may have been flipped to attacker control minutes after creation, implying the multisig could have been compromised almost from birth and used as a staging structure.

It’s a reminder that “multisig” is architecture, not magic. If signer devices are compromised, if the initial owner set is tampered with, or if governance is captured, the multisig simply becomes an attacker-run Safe with better branding.

Chapter 5: Endpoint malware, cross-chain consequences

One of the clearest examples of endpoint compromise around year-end incidents was the babur.sol case: ~$27M stolen spanning a Solana wallet and an Ethereum Safe multisig. Public reporting attributes the initial access to malware execution on the victim’s computer, followed by private key exposure, including keys relevant to the Safe.

The mechanics are classic and ugly:

• the attacker wins the machine,
• the machine yields keys or seed backups or signing capability,
• the attacker signs valid transactions on multiple networks,
• the theft crosses ecosystems because the user does.

In a sense, this is the purest “blockchain attack” story: Nothing happened to the blockchain. The blockchains worked fine. The user’s endpoint didn’t.

Chapter 6: When governance is the exploit surface

The final category is the one defenders dread because it looks like legitimate admin activity until it’s too late: Governance and upgrade privileges.

Unleash Protocol (Story ecosystem) suffered an unauthorized contract upgrade and subsequent asset transfers, attributed to governance privilege compromise (multisig authority abused). Stolen assets were reported across several tokens with confirmed losses around $3.9M, followed by incident response actions and public comms.

This pattern is consistent across ecosystems:

1. attacker obtains enough governance power (stolen signer key, compromised signer device, misconfigured threshold),
2. attacker upgrades implementation or changes privileged parameters,
3. attacker drains value with “valid” admin calls.

The most sobering part is that many monitors won’t alert on an “upgrade” because upgrades happen all the time.

Epilogue: A network-level bug and a validator halt

Then, on Dec 27, the story goes from userland and app-land to chain operations.

Flow Foundation confirmed an exploit of a Flow execution layer vulnerability. About $3.9M was moved off-network before validators coordinated a network halt. Reporting describes bridging out via common cross-chain rails and a response that involved validators, bridges, and exchanges. Debate followed about rollback vs targeted recovery; public coverage notes Flow moved away from a full rollback after backlash.

This is the holiday nightmare scenario for a chain: exploit plus urgency plus governance decisions under pressure, with every option carrying tradeoffs.

So are we doomed? The good news is: “The answer is no”. There are ways to secure digital assets, using new generation of tools and with adequate education for users.

Happy New Year 2026… Stay safe!