Safe Labs Address Poisoning Campaign: $3.02M Lost to Coordinated Vanity Address Social Engineering

Attack: Safe Labs Address Poisoning Campaign | Loss: $3,020,000 | Type: phishing | Chain: Multiple

Executive Summary

In early 2026, a coordinated address poisoning campaign targeted Safe (formerly Gnosis Safe) users across multiple EVM chains, deploying approximately 5,000 vanity addresses crafted to visually mimic wallet addresses appearing in victims' prior transaction histories. The largest single victim lost $3.02 million after signing a malicious 'permit' or 'increaseAllowance' transaction, granting the attacker full token allowance without an on-chain fund transfer that would have triggered immediate suspicion. The campaign is notable for its industrial scale — 5,000 poisoning addresses represents a systematic, automated operation rather than opportunistic fraud — and for targeting Safe multisig users, a cohort that typically operates with higher-than-average security awareness. This incident demonstrates that UX-layer trust signals, specifically transaction history displays, remain a critical and underdefended attack surface.

What Happened

Address poisoning as a technique has existed since at least 2022, but the January 2026 Safe Labs campaign represents a significant escalation in operational scale and targeting sophistication. The attackers did not compromise any Safe Labs infrastructure. No smart contract vulnerability was exploited. The attack surface was entirely human: the tendency of users to copy recipient addresses from prior transaction history rather than from a verified primary source.

The mechanics of address poisoning rely on vanity address generation — a computationally intensive but well-documented technique whereby an attacker brute-forces private key generation until a resulting public address shares a matching prefix and suffix with a legitimate target address. Most wallet interfaces display only the first 6 and last 4 characters of a 42-character hexadecimal address, creating a 38-character blind spot. With GPU clusters or cloud compute, generating convincing lookalike addresses is a matter of hours to days per target, and the process is fully automatable at scale.

The campaign deployed roughly 5,000 such poisoning addresses. Attackers seeded victims' transaction histories by sending zero-value or dust transactions from the lookalike addresses to the target wallets. This is the poisoning step — the goal is not fund theft at this stage, but to insert a fraudulent address into the victim's on-chain history so it appears as a known counterparty. When the victim next copies an address from their wallet's transaction history UI, they may copy the attacker's address instead of the legitimate one, particularly if they rely on partial visual matching rather than full verification.

In the largest confirmed incident, the victim signed a 'permit' or 'increaseAllowance' transaction rather than a direct transfer. This is a particularly dangerous variant of the attack. ERC-20 permit functions, standardized under EIP-2612, allow token allowances to be set via an off-chain signature rather than an on-chain approval transaction. This means the victim may have been presented with a signing request that did not require broadcasting a visible transaction before the attacker could drain funds. The increaseAllowance variant similarly grants a spender — in this case, an attacker-controlled address — the right to transfer tokens on the signer's behalf up to a specified amount. In either scenario, once signed, the attacker can call transferFrom to move $3.02 million in a single subsequent transaction with no further victim interaction required.

The specific timing and full scope of the campaign remain partially unverified due to the January 2026 date, but on-chain forensics patterns consistent with prior address poisoning campaigns suggest the attacker likely operated a backend system that monitored mempool activity, identified high-value Safe wallets, generated targeted lookalike addresses per wallet, and executed dust poisoning transactions systematically. This is not a script kiddie operation. The infrastructure required to generate and deploy 5,000 targeted vanity addresses at campaign scale implies prior planning, compute resources, and operational security discipline on the attacker's part.

The incident is a direct challenge to the assumption that multisig wallet users — Safe's core demographic — are inherently more security-conscious and therefore less vulnerable to social engineering. Multisig protects against key compromise. It does not protect against a legitimate keyholder signing a malicious transaction that they believe to be legitimate. The attack bypassed the security model entirely by targeting the verification gap between what users see and what they sign.

Kill Chain

1. Target Reconnaissance — Attackers identify high-value Safe multisig wallets across Ethereum and EVM-compatible chains by monitoring on-chain activity, wallet balances, and transaction frequency. Wallets with regular outbound transfers to recurring counterparties are prioritized — these users are most likely to copy addresses from transaction history rather than re-verify from source.

2. Vanity Address Generation and Poisoning — For each target, attackers generate vanity addresses that match the first 6 and last 4 characters of legitimate counterparty addresses in the victim's transaction history. Approximately 5,000 such addresses were deployed in this campaign. Dust or zero-value transactions are sent from these lookalike addresses to the victim wallet, inserting the fraudulent address into the wallet's visible transaction history.

3. Victim Self-Compromise via Address Copy — When the victim initiates a legitimate outbound transfer, they copy the recipient address from transaction history — a common shortcut — and select the attacker's lookalike address instead of the legitimate counterparty. In the $3.02M incident, the victim is presented with or constructs a transaction invoking a permit or increaseAllowance function, signing over token allowance to the attacker-controlled address.

4. Allowance Drain via transferFrom — With a valid off-chain signature granting token allowance, or a confirmed on-chain increaseAllowance approval, the attacker calls transferFrom on the relevant ERC-20 contract, moving $3.02 million to attacker-controlled wallets in a single transaction. Funds are subsequently moved through mixers or cross-chain bridges to obscure the trail.

Where Users Failed Themselves

• Copying recipient addresses from wallet transaction history UI rather than from a verified primary source (bookmark, ENS name resolved fresh, hardware-confirmed address). The entire attack depended on this single habit. One full address comparison would have broken the kill chain.
• Signing a permit or increaseAllowance transaction without fully decoding and auditing the calldata. These function signatures do not trigger a visible on-chain transfer — they generate an off-chain approval that looks like a routine signature request. Users treating signature requests as low-stakes actions exposed themselves to a $3.02M loss from a single click.
• Failing to use address book features with verified entries. Safe's own interface supports labeled address books. Pinning known counterparties to verified, labeled entries and never transacting with an address outside that book removes the entire poisoning vector. Users who operated without a curated address book remained vulnerable to the transaction history substitution.
• Relying on partial address visual matching (first/last few characters) rather than full 42-character verification. This is a trained habit reinforced by wallet UI design but it is operationally equivalent to verifying an 8-character password on a 42-character credential.
• Not querying or auditing existing token allowances before signing new approval-type transactions. A routine check via tools like Revoke.cash or Etherscan's token approval interface would have revealed anomalous pending allowances and provided a second detection opportunity.

Prevention Checklist

For individual users

• Never copy a recipient address from transaction history. Maintain a verified address book inside Safe or in a separate credential manager. Add new addresses only after full 42-character manual verification against a source independent of your wallet UI.
• Treat every signature request — including permit, increaseAllowance, approve, and signTypedData calls — as equivalent in risk to a direct transfer. Decode the calldata or use a transaction simulation tool (Tenderly, Fire, Pocket Universe) before signing. If you cannot read what you are signing, do not sign it.
• Audit active token allowances on a scheduled basis using Revoke.cash or equivalent. Revoke any allowance not tied to an active, verified protocol interaction. A zero-allowance posture eliminates the exploitability of any inadvertent permit signature.
• Enable hardware wallet confirmation for all Safe transactions and treat the hardware device display as the authoritative source of recipient address — not the browser or app UI. Hardware wallets that display full addresses (Ledger, Trezor) provide an out-of-band verification step that defeats UI spoofing.

For protocols & projects

• Safe Labs should implement native transaction simulation with decoded human-readable calldata displayed before any signing step. Users must see 'You are granting [ADDRESS] permission to spend up to [AMOUNT] of [TOKEN]' in plain language — not raw hex.
• Integrate allowance-change warnings directly into the Safe UI: any transaction that modifies a token allowance should trigger a mandatory confirmation dialog displaying the full spender address, token, and amount, distinct from standard transfer confirmations.
• Implement an address entropy warning system that flags when a recipient address shares a high degree of prefix/suffix similarity with other addresses in the wallet's transaction history. A simple Hamming distance check on known-good addresses would surface poisoning attempts before funds move.
• Add optional transaction history filtering to suppress zero-value and dust transactions from the primary history view, or visually differentiate them. Poisoning only works if the malicious dust transaction appears indistinguishable from legitimate history entries.

Key Takeaway

Address poisoning kills you with your own habits: the moment you copy a recipient address from transaction history instead of a verified source, you have handed the attacker control of the transaction. Full 42-character address verification before every outbound transfer is not optional hygiene — it is the only technical control that directly defeats this attack class, and no protocol or ecosystem safeguard substitutes for it.

Sources

• Safe (formerly Gnosis Safe) official documentation and security advisories: https://safe.global
• EIP-2612: Permit Extension for EIP-20 Signed Approvals — https://eips.ethereum.org/EIPS/eip-2612
• ZachXBT on-chain investigation threads (X/Twitter) — address poisoning campaign reporting, 2024-2026
• Revoke.cash token allowance auditing tool — https://revoke.cash
• Coinbase and MetaMask security blog coverage of address poisoning techniques, 2023-2024
• Forta Network threat detection documentation — https://forta.org
• Tenderly transaction simulation platform — https://tenderly.co
• Chainabuse community threat reporting database — https://www.chainabuse.com

ZeroTraceLabs — zero-trust crypto security. zerotracelabs.xyz