Wallet drainers are among the most economically significant attack patterns in Web3-environment and among the most frequently misunderstood. Unlike the classic theft of a seed phrase, the perpetrator does not need access to the key material. They only need one action from the user: a signature.
From the blockchain's perspective, a drainer attack is therefore initially inconspicuous. There is no intrusion, no security vulnerability in the protocol, and no compromised cryptography. There is a formally correctly authorized transaction. The user has indeed signed, but typically hasn't understood what rights of disposal they have thereby granted.
This article describes the authorization mechanism behind drainer attacks, classifies the current vectors, including delegation-based attacks, according to EIP-7702 Drainer clearly distinguishes itself from sweeper bots and Solana-specific variants, and shows which traces can be analyzed on-chain and which cannot. It is aimed at lawyers, companies, and investigators, but is also accessible to those directly affected without a technical background. Those who simply want to know what to do now will find the steps below under "Immediate Actions.".
What a wallet drainer is and what it isn't
A wallet drainer is not a single program, but an infrastructure. It typically includes a convincingly designed deceptive user interface, wallet connectivity via standard provider interfaces, server-side evaluation logic, pre-configured signature or transaction requests, one or more smart contracts, target and collection wallets, and downstream obfuscation mechanisms.
The key feature: In classic approval and PermitIn -based attacks, the perpetrator does not gain universal control over the wallet, but rather access limited to the specific authorization granted. This is precisely what defines both the limits of the damage and the possibilities for countermeasures, and both fundamentally distinguish a drainer attack from a complete compromise by a Sweeper Bot. However, delegation-based mechanisms such as EIP-7702 can significantly extend this limit; see the section on delegation-based attacks.
Equally important is what a drainer is not: It does not exploit a flaw in the blockchain. It exploits the fact that cryptographic signatures and smart contract permissions are technically binding and that the representation of what is being signed takes place in the wallet interface—a layer that can be manipulated, incomplete, or simply incomprehensible. We have outlined the methodological foundations of our work on such cases in the whitepaper on... Blockchain forensics summarized.
The attack sequence of the Wallet Drainer in six phases
In practice, the process follows a stable pattern that provides the framework for forensic reconstruction.
Bait. The victim obtains the product via counterfeit airdrops, NFT mints, TokenClaims, staking or bridge offers, compromised social media accounts, paid search ads, or purported security checks leading to a deceptive website are all common scams. Increasingly relevant are imitations of well-known protocols operating under visually similar domains.
Connection. The user connects their wallet. This step in itself is not yet authorization, but it is the point at which the other party learns the address.
Evaluation. The drainer infrastructure reads and prioritizes the portfolio holdings. Which signature request is displayed to the victim depends on which asset promises the highest return and through which mechanism it can flow out most quickly. This step is the reason why drainer interfaces generate different requests for different victims.
Authorization. The user signs, be it a release, a message, a delegation or an immediately effective transaction.
Execution. The entitlement is redeemed, in many cases bundled across multiple assets in a single transaction.
Redirect. The loot is passed on to pooled wallets, divided, swapped, moved via bridges, and finally dumped at an off-ramp. The obfuscation methods used include mixing services, the forensic limitations of which we discuss below. Crypto mixers in a compliance and forensics context represent.
This has an important consequence for the investigation: the drain is the end of the chain, not its beginning. The forensically decisive events lie before it.
The authorization mechanism in detail: Approvals, Permit and Delegation
Token Approvals as an Entry Point
On Ethereum and EVM-compatible chains, the ERC-20The standard allows a so-called donor, i.e., an address or a smart contract, to transfer tokens on behalf of the holder. This function is legitimate and essential for decentralized exchanges, bridges, and lending protocols.
It becomes abusive when the release is granted to a contract controlled by the perpetrator. This contract can then be used via transferFrom Access the released amount without requiring any further action from the victim.
Two factors exacerbate the problem. First, many applications request unlimited or extremely high permissions for fee reasons, meaning the authorization far exceeds the actual reason for it. Second, a granted permission generally remains on-chain until it is modified, revoked, or consumed, depending on the mechanism. Disconnecting the wallet connection from the website only ends the session within the application; the on-chain state remains unaffected.
NFT shares and setApprovalForAll
Similar principles apply to NFTs, but with a broader scope. In addition to releasing individual tokens, the standards allow... ERC-721 ERC-1155's `setApprovalForAll` allows the authorization of an operator for the entire collection of contracts. If this operator is controlled by the attacker, all NFTs in that collection can be transferred without renewed approval. For valuable collections, this can result in significant damage in a single transaction.
Permit and Permit2: Release without a visible transaction
Newer methods shift the authorization from the transaction to the signature. According to ERC-2612 (permit) and in the widely used Permit2In this model, the user generates a structured signature according to EIP-712, which authorizes a release or, in the case of the signature transfer variant, even a transfer directly. It is later redeemed on-chain by another party.
For legitimate applications, this saves a transaction and fees. Phishing This results in a double advantage:
No fee, no alarm. To the victim, the request looks like a harmless confirmation because there are no transaction fees and the wallet often only displays structured data.
Temporal decoupling. Hours or days can pass between signature and asset outflow. How long the signature remains usable depends in particular on the stored expiration time and the associated... Nonce and depends on the respective authorization mechanism. This makes it considerably more difficult to attribute cause and effect, even for the person affected, who may misjudge the timing of the incident.
The forensic consequences are serious: The signature itself leaves no trace on the blockchain. Only its redemption by the donor is visible. Proof that and when the victim signed must therefore come from other sources, such as browser and device artifacts, the application's wallet history, or communication. We have discussed which evidence is sufficient for filing a criminal complaint and claiming restitution under [link to relevant section]. Prove crypto fraud compiled.
Directly signed transactions and bundling
Not every drainer operates via permissions. In many cases, a transaction is simply presented for confirmation, which then calls a contract belonging to the perpetrator. This is done via aggregator or... MulticallPatterns allow multiple processes, such as releasing, transferring, and withdrawing native coins, to be bundled into a single confirmation step. From the user's perspective, it's one click; from the blockchain's perspective, it's multiple asset transactions.
Delegation-based attacks according to EIP-7702
With the Pectra upgrade (activation on the Ethereum mainnet on May 7, 2025), external accounts (EOAs) can delegate execution rights to a smart contract via EIP-7702. This is intended for third-party fee coverage, spending limits, and bundled transactions.
This creates a new dimension for drainers: Instead of individual token releases, the victim is presented with a delegation for signature, often disguised as a security or convenience wallet upgrade. After delegation, the account executes the code of the stored delegate contract within the context of its own account when the corresponding commands are requested. This code alone determines which transactions are possible, up to and including the transfer of native coins. The EIP specification explicitly points out that faulty or malicious delegate contracts can grant almost complete control over the account.
To give an idea of the scale: Wintermute Research published an analysis on May 30, 2025, showing that more than 97 percent of the delegations registered up to that point referenced contracts with identical bytecode. The most frequently copied version was decompiled, released as Solidity, and labeled "CrimeEnjoyor"; its current status can be viewed via the team's Dune dashboard.
This figure, however, must be interpreted carefully, and Wintermute explicitly clarified its meaning a few days later: The percentage says nothing about a weakness in the standard, nor about the security of common wallets. It describes a then-small total number of delegations, dominated by automated sweeper delegations on already compromised keys. Reputable wallet implementations should only allow delegations via controlled and audited mechanisms; the specification itself warns against providing users with any signature interface for authorizations, because the delegated code gains extensive access to the account.
The variant relevant for drainers is the other: delegations that the victim authorizes themselves via a deceptive interface. Such cases have been documented since May 2025, and established phishing toolkits have now incorporated delegation payloads into their transaction templates.
Two constellations must be distinguished:
Delegation through phishing. The victim signs the delegation themselves. This is a drainer case.
Delegation after key outflow. The perpetrator already possesses the private key and uses delegation to automatically and lump-sum withdraw incoming amounts. This is a Sweeper Fall with a new technical foundation.
Both generate similar on-chain traces. The distinction only arises from the question of who authorized the delegation.
Solana: Owner Reassignment and Durable Nonces
Solana does not have an approval model in the EVM sense, but it does have functionally comparable and in some cases more extensive mechanisms:
Delegation. A delegate for a token account can be designated via the approve instruction of the token program.
Change of owner authority. The `SetAuthority` instruction allows you to transfer the owner authority of a token account to another address. Once this takes effect, the previous owner loses control over that token account; their key remains valid for the other accounts in the wallet. This does not result in a general compromise, but it does lead to a permanent loss of the affected tokens. It's important to note the terminology: this refers to the authority stored in the token account state, not the program to which the account is assigned.
Such a change of authority does not, in itself, trigger a transfer or a change in the balance. Interfaces that do not clearly display and highlight changes in authority therefore present the process less conspicuously than a visible outflow of assets. This pattern corresponds to the silent restructuring of account authorizations known from TRON.
Durable Nonces. Regular Solana transactions expire after a short time because the referenced block hash expires. A transaction bound via a nonce account, however, remains valid as long as the durable nonce used has not been consumed or passed on; it can therefore be submitted considerably later. This is intended for offline signatures and multi-stage approvals.
The potential impact of this mechanism was demonstrated by the Drift Protocol incident on April 1, 2026: Pre-signed multisig transactions obtained through deception were intercepted and then used within a few slots to seize administrative privileges. In its April 16, 2026, update, Drift detailed the stolen assets at approximately $295.7 million and estimated outstanding user losses at around $295 million; independent analysts had initially reported losses of approximately $285 to $286 million. For the relaunch, Drift announced, among other things, the deactivation of durable nonces for all signers. While the incident wasn't a classic wallet drain against an end user, but rather a governance and multisig compromise, it perfectly illustrates the forensically relevant temporal decoupling of signature and execution.
For those affected and investigators, this means that on Solana the question "When was it signed?" is even more decoupled from the question "When was it executed?" than on EVM chains.
Blind signing and simulation circumvention as risk conditions
Blind signing is not an attack type, but rather the risk condition that makes most of the described vectors practical: The user confirms a transaction or message whose content and consequences are not fully displayed or clearly explained, for example because only raw data appears, because the called contract function is not resolved, or because warnings are routinely clicked away.
A hardware wallet offers only limited protection. The private key never leaves the device, but a malicious authorization will be signed just as correctly as a legitimate one. The crucial factor is not only where the key is located, but what is being authorized.
Even transaction simulations do not offer complete protection. A gap exists between verification and execution, which is deliberately exploited: contracts can detect that they are being executed in a simulation and behave inconspicuously there; updatable contracts or logic subsequently rewritten via proxy patterns can have a different effect after signing than before; and target addresses can be pre-calculated using deterministic deployment methods, so that the malicious code does not even exist at the time of verification.
Why only certain assets often disappear when a wallet drainer occurs
In a permission-based attack, the entire wallet is not necessarily emptied. Only what the granted permission covers is affected: a specific token type, a specific NFT collection, a specific contract.
On EVM chains, the native coin, such as ETH or BNB, is not covered by a classic ERC-20 or NFT approval because its transfer requires a separate transaction signed with the key. Solana uses its own authorization mechanisms as described above. This very pattern is strong evidence against key compromise: if native coins remain while individual tokens disappear, it suggests an approval or permit issue.
The converse, however, is not true. Even in the case of a drainer, native coins can flow out if the victim has signed an immediately effective transfer transaction or if a delegation according to EIP-7702 exists. The finding "ETH is also gone" therefore does not prove seed compromise; it merely shifts the burden of proof to the question of which authorization underpinned the outflow. If, on the other hand, the investigation reveals that key material has flowed out, the detection patterns of a key compromise apply.
Wallet Drainer and Sweeper Bot: the distinction
| criterion | Wallet Drainer | Sweeper Bot |
|---|---|---|
| Prerequisite for the perpetrator | Signature, release, or delegation granted by the victim | Seed phrase or private key |
| reach | Limited to authorized use | Full control over the address |
| time | One-time use or until the entitlement expires | Permanent, automatically responds to every access |
| Native Coins | Only in the case of a directly signed transfer or delegation | Regularly affected |
| Effective countermeasure | Revoke permissions, reset delegation | Give up address, migrate assets |
The practically most important sentence of this comparison is: A release can be revoked, a known key cannot.
However, these two patterns are not mutually exclusive. A typical scenario begins with a malicious share and continues when the victim subsequently reveals their seed phrase via fake support or a purported recovery offer. A limited drainer attack then escalates into a complete compromise. We have investigated which providers and structures are behind this second wave below. Crypto Fraud Recovery Scam analyzed. Therefore, the investigation should never prematurely assume a single mechanism.
Drainer-as-a-Service: Division of Labor in Offender Structures
Professional crypto fraud is organized with a division of labor. Developers provide the drainer software, operators maintain the infrastructure, affiliates recruit victims via phishing sites, advertisements, or compromised social media accounts, and other actors handle forwarding and disbursement. The proceeds are divided according to a pre-defined key, often immediately and automatically. We describe the structure of these networks in detail in our whitepaper on... Anatomy of professional crypto scammers.
This has two consequences for investigations. First, the person who contacted the victim is not necessarily the person operating the infrastructure. Second, and forensically valuable, the automated revenue splitting generates a characteristic on-chain pattern. Recurring percentage splits to a constant address across many unrelated victims strongly suggest a service structure and provide a good starting point for forming address clusters. We demonstrate how the individuals behind this can be further narrowed down using open sources below. OSINT in fraud cases.
On-chain detection: Indicators of a drainer attack
A single outflow of assets does not prove the existence of a drainer. A reliable classification only emerges through the reconstruction of the chain of events. Typical indicators:
Release immediately before drainage. Shortly before the transfer, an unknown contract was granted permission, as can be seen in the corresponding event log of the release.
Outflow through a third party. The transfer is not carried out as a direct transaction by the victim, but rather as a request from an external donor who redeems the authorization. The gas consumption is then charged to the perpetrator, not the victim.
Redemption without a matching release transaction. If a suitable on-chain release is missing in the immediately preceding history, even though an external donor is transferring, one of the possible causes to consider is an off-chain generated permit or signature authorization. Other possibilities include older permissions, operator rights, differing token logic, or an existing delegation.
Bundling. Multiple assets are transferred to the same or related addresses in one or a few consecutive transactions.
Delegation markers. EIP-7702 has a delegation reference stored in the account; despite its EOA nature, the account behaves like a contract. Comparing the stored target address with known sweeper bytecode families is a quick and informative test.
Selectivity. Native coins remain unaffected, while certain tokens disappear.
Recurring patterns. Multiple victims interact with the same contracts, donor or target addresses; the loot is divided according to constant quotas.
Immediate forwarding. Incoming funds are forwarded to pooled wallets without any holding period.
In addition, Solana features specific markers: an instruction that changes the owner of a token account without any balance movement, and the use of a nonce account, which indicates a signature generated significantly earlier.
Our analyses show how such chains can be evaluated across Layer 2 networks and bridges. Polygon in crypto forensics and to forensic analysis of an arbitrum swap.
Forensic approach in drainer cases
Working backwards. The starting point is the outflow; the object of investigation is the chain leading up to it: contract interactions, approvals, delegations, unusual signature times. The chronology, not the individual finding, supports the conclusion. We describe the methodological foundations and limitations of this work below. Crypto forensics in practice.
Closing the off-chain gap. The authorization process is invisible in on-chain permit and signature phishing. Therefore, browser history, cache, wallet activity logs, visited domains, advertising and referral chains, and communication histories are not secondary but often crucial evidence for the timing and context of the signature. This data should be backed up early and without alteration.
Secure evidence. At a minimum, the following must be documented: affected address, transaction hashes, block heights and timestamps in UTC, token and contract addresses, release and delegation operations, destination and redirect addresses, suspicious domains, as well as screenshots and communication. A potentially compromised endpoint should no longer be used for sensitive operations and should be properly secured before any cleanup.
Reconstruct path. A typical sequence of events: deceptive website, wallet connection, authorization, outflow, drainer address, pooled wallet, swap or bridge, off-ramp. If the funds reach a regulated exchange, a realistic starting point for information and seizure requests from law enforcement arises. In the case of stablecoins, a block by the issuer is also a possibility, as we discuss below. Freeze USDC represent.
Conduct attribution in a disciplined manner. The first recipient address is not the perpetrator. It could be an automated drainer contract, a collection or intermediary address, or the wallet of another participant. A strict distinction must be made between technical observation, analytical hypothesis, and personal attribution, and this distinction must be clearly indicated in the report.
Legal classification. Depending on the circumstances, the following offenses may be considered: fraud (§ 263 of the German Criminal Code), computer fraud (§ 263a of the German Criminal Code), data espionage (§ 202a of the German Criminal Code), and data manipulation (§ 303a of the German Criminal Code); the specific elements of each offense must be examined on a case-by-case basis. A criminal complaint should be filed promptly; for companies, this should be done through the central cybercrime contact points of the state criminal police offices. For information on the civil law classification of stolen crypto assets, please see our section on [topic missing in original text]. Legal classification of stolen cryptocurrencies in phishing cases, regarding the statute of limitations aspects, see the white paper on Deadlines in cases of crypto and investment fraud. This is for guidance only, not legal advice.
Immediate measures for victims after a wallet drainer attack
No further signatures. Neither on the website in question nor on alleged testing or rescue services.
Plan damage control according to the mechanism. Depending on the identified attack pattern, remaining assets should be transferred to newly generated key material and/or malicious permissions and delegations revoked. The order is not universal: a transfer itself requires further interaction, while an active permission can still be used. Therefore, it should be derived from the specific findings.
Review and revoke permissions. Reset existing token and NFT releases; for EIP-7702, also revoke the delegation. Revoking a release incurs network fees and only takes effect prospectively.
Securing evidence, before browser data or devices are cleaned.
Determine the cause. The crucial question is whether only authorization was misused or whether key material was also leaked. This determines whether a revocation is sufficient.
Do not accept any recovery offers. A second wave of fraud regularly follows one incident. No reputable service provider ever requires a seed phrase or private key. Our tool enables a structured initial assessment of such offers. Crypto Recovery Scam Check.
Revoking authorization only protects against its future use. It does not recover assets that have already been transferred. And it is completely ineffective if the key is also known, the device is compromised, or a delegation remains active.
One risk is regularly underestimated in this situation: Anyone who forwards payments or provides accounts after the incident can themselves become subject to money laundering proceedings. We describe this scenario below. Fraud victims as unwitting money launderers.
Prevention: Effectively avoid wallet drainers
Separate wallets according to their purpose. A wallet for long-term storage should not be the same one that interacts with new applications.
Limit releases and regularly revoke permissions that are no longer needed; avoid unlimited allowances.
Read signature requests. Do not confirm unexpected or unresolvable requests, especially delegations and structured signatures without apparent reason.
Verify the origin of the surface. No calls via links from direct messages, comments, or advertisements.
Hardware wallet for valuable assets, with conscious verification of the signature contents on the device.
For company assets Multisignature or MPC custody with documented dual control; for governance rights, additionally regulate the handling of pre-signed transactions. We describe how we support companies in prevention and education under [link/section name]. Financial forensics for companies.
What wallet drainers mean for law firms, companies and individuals
For lawyers, the distinction between abuse of authority and key compromise is crucial to the outcome of a case, as it determines the scope of damages claims, the extent of the evidence to be presented, and the likelihood of success of a seizure request. We describe how we support law firms under [link/section name]. Financial Forensics for Lawyers; We provide support for ongoing investigations under for prosecutors dar.
Private individuals who initially need a preliminary assessment of their case can find information under our brand. Crypto Investigation the right starting point. Our analysis services provide an overview in our Services.
Conclusion: It is not the blockchain that is being attacked, but the authorization process.
Wallet drainers do not attack the blockchain itself, but rather the interface between the user and authorization. Their effectiveness relies on the fact that while a signature is technically binding, its meaning is often not apparent to the signer. The current evolution of permission signatures, from EIP-7702 delegations to Solana authority transfers, is shifting this gap further in favor of the attacker, because the harmful effects are becoming increasingly invisible, delayed, and widespread.
For those affected, therefore, a single question is crucial: Was an authorization misused, or was the wallet as a whole compromised? This determines whether a revocation is sufficient or whether all assets must be migrated to new key material.
From a forensic perspective, the starting point is more favorable than it appears. Approvals, delegations, contract interactions, transfers, and forwardings are permanently documented and can be evaluated chronologically. Where the authorization act occurs off-chain, the securing of device and communication traces takes its place. The combination of both levels and clearly separated attribution creates the crucial starting points: drainer structures, pooled wallets, and regulated off-ramps. We describe the overall strategy that can be derived from this below. Recover stolen cryptocurrencies. For the classification of a specific case Contact us.
FAQs: Wallet Drainer
Not necessarily. If the incident only concerns a specific release or signature, the key material remains unaffected. However, this is a finding that should be verified, not assumed, especially if native coins have also been transferred.
The wallet itself contains nothing that can be removed. Permissions can be revoked; delegations can be reset. The perpetrator's infrastructure remains unaffected.
No. This only ends the session within the application. On-chain permissions and delegations remain unchanged.
With permit signatures and pre-signed transactions using a durable nonce, the redemption time is decoupled from the signature time. The conspicuous event then occurs well before the outflow.
Yes, it protects against key theft; no, it protects against unauthorized authorization. Anything the user confirms is correctly signed.
Only if permissions are affected. If the key is compromised, malware is active, or delegation is in place, the address must be treated as lost. We discuss in detail when a revocation is sufficient and when it is not in our article on Sweeper Bots. (in preparation).
The extent of the outflow and whether key material is affected are key indicators. If native coins remain and only individual tokens disappear, this suggests a drainer. A detailed comparison is provided by the Sweeper post.
If operator authorization has been granted according to ERC-721 or ERC-1155, all NFTs of the affected collection can be transferred without renewed consent.
No. It reconstructs the flow of funds and provides the basis for requests for information and security. Exchanges, issuers, authorities, and courts decide on security measures.
Do not provide any further signatures, secure the evidence unchanged, have the mechanism clarified, and only then decide on revocation or migration.
