Wallet Drainer, Private-Key Theft, or Scam Transfer? What On-Chain Evidence Can Reveal

Intro

"My wallet was hacked." Every crypto investigation team hears this sentence multiple times a week. And in almost every case, it describes the outcome — not the diagnosis. The balance was there. The assets moved. The recipient is unknown. The transaction cannot be reversed. From the victim's perspective, five completely different technical incidents can feel identical. But technically, the events behind that sentence may have nothing in common. An attacker may have obtained the private key and signed the transaction directly. The victim may have unknowingly given a malicious smart contract permission to move tokens weeks earlier. The victim may have intentionally signed and sent a transfer — after being deceived about who the recipient was. The victim may have copied an address-poisoning lookalike from their own transaction history. Or an attacker may have compromised the victim's exchange account and initiated a withdrawal — without ever touching the blockchain wallet at all.

Each of these requires different evidence. Each may require a different immediate security response. And each leaves a different forensic signature — some visible on-chain, some not.

The first forensic question is not "where did the stolen crypto go?" It is "how did it leave the victim's control?"

A cryptographically valid transaction proves that the required blockchain authorization existed. It does not necessarily prove that the real owner intended the transaction. Understanding the mechanism is what separates a useful investigation from an expensive guess.

Start with the Transaction Mechanism, Not the Victim's Explanation

Victims describe what happened in human terms: "I clicked something." "I never signed anything." "My Ledger was hacked." These descriptions may or may not match the technical reality. Before interpreting the victim's account, an investigator should establish the observable blockchain facts.

1. Direct signed transaction. For an externally owned account (EOA) transaction, examine the from address, the to address, the transaction value, input data, nonce, timestamp, gas parameters, and any subsequent transfers. A valid Ethereum transaction is signed by the private key corresponding to the sending account. But this establishes key-level authorization — it does not establish who used the key.
2. Token movement through a contract. For ERC-20 token movement, investigate the token contract, the Transfer event, the transaction initiator, the token owner, the recipient, the spender, the allowance, any earlier approval transaction, and the smart contract that was called. The ERC-20 standard supports a pattern where an account approves a spender, and that spender later moves tokens using transferFrom. This distinction is essential for identifying approval-based drainers.
3. Custodial withdrawal. If the stolen crypto originated from an exchange, the on-chain record may show an exchange-controlled hot wallet as the sender and an attacker-controlled destination — but the victim's personal address may never appear as the sender at all. This immediately changes the investigation. Determining account takeover requires exchange withdrawal records, login history, session and device data, 2FA changes, recovery changes, email activity, and IP data where the provider retains it.

Five Loss Mechanisms Leave Different Forensic Signatures

Private-Key or Seed-Phrase Compromise

The typical pattern shows transactions originating from the victim's EOA with a valid account signature, directed to attacker-selected recipients. Native assets can move directly. Several token transfers may follow in rapid succession. The attacker may also move the gas or native balance. If a common seed phrase is compromised, multiple derived accounts may be affected.

This pattern supports the interpretation that someone capable of authorizing transactions for the victim's account gained effective control. Strong on-chain signals include the victim address being the transaction sender, no previously granted spender being required for direct movement, and multiple unrelated assets leaving toward attacker-linked addresses.

But the same on-chain pattern could also occur if the user deliberately signed a transaction after deception, if an attacker operated an unlocked device, if malicious software triggered wallet signing, if a remote-access scammer controlled the interface, or if another authorized person used the key. Private-key theft is a strong hypothesis in many of these cases, but on-chain evidence alone does not always confirm it definitively.

Malicious Approval or Wallet Drainer

The typical pattern shows the victim first interacting with a contract or signing a permission — and then, separately, another address or contract moving tokens. Investigators look for an earlier approve transaction, an allowance, a transferFrom call, a permit or signature-based permission, a setApprovalForAll for NFTs, a spender address, a contract interaction preceding the drain, several token contracts accessed by the same spender, and assets moving without a new direct transfer initiated by the victim for each asset.

An approval-based pattern can strongly identify the mechanism used to move a specific token. But "drainer" is an attribution label, not a single technical method. Modern theft may involve approvals, permit signatures, direct malicious transactions, account permissions, or smart-account capabilities. The label may require broader attribution or incident context beyond one approval event.

The social-engineering layer — the fake airdrop, the phishing site, the deceptive dApp — usually precedes the approval.

Scam-Induced Direct Transfer

This case is fundamentally different from the previous two. The victim may enter the recipient address, click Send, confirm the amount, and sign the transaction — knowingly initiating a blockchain transfer — while being completely deceived about who the recipient is, why the funds are being sent, whether the investment exists, whether the support agent is legitimate, or whether the funds will be returned.

Typical examples include investment scams, pig butchering schemes, fake support requests, impersonation, fake exchange deposits, and fake recovery payments. On-chain, the transaction may look completely ordinary: a direct transfer with no malicious token approval, no unauthorized spender, and no exotic contract call. The blockchain can establish that the victim address sent funds, the recipient received them, the sequence and amounts, and the downstream movement. It cannot establish that the victim understood the true purpose, that the scammer made false representations, that a relationship existed, or that psychological manipulation occurred. Those conclusions require chats, websites, emails, payment instructions, and other off-chain evidence.

Address Poisoning

The typical on-chain sequence shows a legitimate prior payment to address A, then an attacker creating a lookalike address B with similar beginning and ending characters, then a tiny or zero-value transaction making B visible in the victim's transaction history, and finally the victim signing a genuine high-value transfer to B instead of A.

On-chain evidence can support the chronological relationship, the visual similarity between A and B, the attacker-controlled receiving flow, the prior poisoning transaction, and the later high-value payment. But it usually cannot prove that the victim copied B from their history or that the victim failed to compare the full address — the exact user-interface action that caused the mistake. Address poisoning is often identified by combining the transaction pattern with the victim's workflow description. For a real investigation, see our address-poisoning case study where $50K was recovered.

Compromised Exchange or Custodial Account

Here the forensic picture is different again. The victim may own crypto economically but not control blockchain private keys. An attacker gains access to the exchange account, email, 2FA, API credentials, authenticated session, or withdrawal workflow.

On-chain, the investigator may see an exchange wallet sending assets to an attacker-controlled destination. The victim's personal address may never appear. Blockchain alone cannot establish whether the victim requested the withdrawal, whether the attacker logged in, whether an API key was abused, whether account recovery was compromised, or whether a platform security control failed. Required off-chain evidence includes exchange account history, withdrawal requests, device and session logs, email notifications, 2FA history, allowlist changes, and platform support records.

Some On-Chain Patterns Overlap

Several mechanisms can produce similar-looking transactions.

Consider a case where a victim's EOA sends 100,000 USDT directly to an attacker. This single observation is consistent with multiple explanations: the attacker had the private key; malware used signing access; a remote-access scammer controlled the device; the victim intentionally signed after social engineering; the victim copied a poisoned address; or an authorized employee made a fraudulent transfer. The blockchain observes: Wallet A → Wallet B → 100,000 USDT. It cannot see the conversation or the person at the keyboard.

Similarly, when tokens move using transferFrom, this strongly indicates that a spender permission existed. But it does not independently reveal how the approval was obtained, whether the approval was legitimate when created, whether the spender later became compromised, whether the user understood the permission, or whether the attacker was a phishing operator or a compromised legitimate dApp.

The forensic rule: do not infer more than evidence supports. Use language such as "consistent with," "transaction mechanism indicates," "on-chain evidence supports," "further evidence required to confirm." Avoid "proves," "definitely," "confirms" when blockchain alone cannot reach that conclusion.

The destination does not diagnose the attack vector. Stolen funds from a key compromise, a wallet drainer, a scam transfer, and an exchange takeover may all end up at the same recipient address, the same exchange, or the same laundering infrastructure. The fact that funds reached a particular wallet, mixer, or service tells investigators where the assets went — it does not tell them how the assets left the victim's control. Tracing the destination is essential for recovery, but it is not a substitute for diagnosing the initial mechanism.

Downstream laundering does not diagnose the initial theft. After funds leave the victim, the attacker may split assets across wallets, swap tokens, bridge across chains, deposit on exchanges, or use mixers. These post-theft movements are critical for tracing and recovery — but they describe the attacker's behavior after gaining control, not the method used to gain control in the first place. A sophisticated laundering chain after a simple scam payment and an identical laundering chain after a private-key compromise create the same downstream pattern. The laundering is the same; the cause is not.

On-Chain Evidence Answers "How"; Off-Chain Evidence Often Answers "Why"

Blockchain and off-chain records answer different questions about the same incident. Organizing the evidence by question — rather than by source — clarifies what each layer can contribute.

Who or what authorized the blockchain action? The transaction signature, transaction sender, smart-contract call, spender, allowance, approval, token events, and account implementation are all visible on-chain. This layer can usually establish the technical mechanism that authorized the movement.

Did the real owner intend the transaction? Wallet screenshots, signing prompts, browser history, device timeline, communications, remote-access software, scam instructions, and witness accounts are mostly off-chain. The blockchain records that a valid authorization existed — but it cannot reveal whether the human who should have been in control was actually the one who acted.

Was a key or seed exposed? Device forensic findings, malware, seed phrases stored in cloud or email, phishing submissions, export history, and compromise of multiple derived accounts all help answer this question. The blockchain may show the consequences — multiple accounts drained, assets leaving in rapid succession — but it generally cannot reveal the exact moment or method by which the secret was stolen.

Was a malicious approval involved? The approval transaction, spender address, allowance amount, subsequent transferFrom call, contract attribution, and the wallet or dApp interaction that preceded the approval are mostly on-chain. This is one of the scenarios where on-chain evidence can often provide relatively strong technical differentiation — the approval and the subsequent drain create a visible two-step pattern.

Was the victim deceived into sending the funds? Chats, fake investment dashboards, emails, websites, payment instructions, the recipient address supplied by the scammer, and the relationship timeline establish deception. The blockchain transaction proves the payment happened. The communications establish why the victim sent it. Without both, the picture is incomplete.

Was an exchange account taken over? Account logs, withdrawal history, IP and session records, device changes, 2FA history, API activity, and exchange support correspondence explain who requested the withdrawal. The blockchain confirms where it went. The custodian's records explain who initiated it.

In practice, technical on-chain findings and off-chain records should remain linked to their source throughout the investigation. For more on how blockchain evidence should be preserved for legal review, see our evidence-preservation guide.

A Forensic Decision Tree After Crypto Leaves Unexpectedly

Rather than a generic ten-step workflow, the following branching questions help narrow the mechanism before tracing begins.

Question 1 — Did the funds leave a self-custody wallet or an exchange account? If the funds left an exchange account, the investigation moves immediately to account-takeover evidence: withdrawal records, sessions, 2FA history, support correspondence, and the destination TxID. Do not diagnose private-key theft for a key the user never controlled. If the funds left a self-custody wallet, continue.

Question 2 — Was the victim address the transaction sender? If yes, the possibilities include private-key or control compromise, a user-signed scam transfer, address poisoning, or malware-assisted signing — context is needed to narrow further. If no, check whether a token spender, a contract, an exchange or custodian, a smart account, or a delegated permission initiated the movement.

Question 3 — Were tokens moved through an existing permission? Look for an approval, allowance, spender, transferFrom, permit, or operator permission. If a pre-existing permission is found, approval-based theft becomes materially more plausible. Determine when and how the permission was created.

Question 4 — Did the victim intend to send a transaction at that time? If yes, the follow-up questions are: was the recipient the intended person? Did the victim choose the address? Was the address copied from history? Were they following scam instructions? These separate an ordinary scam payment from address poisoning from an intentional legitimate transfer later disputed. If no, investigate key compromise, malware, device compromise, session or account takeover, or pre-existing approvals.

Question 5 — Are multiple accounts or assets affected? Patterns help scope the compromise: one token moved through one spender, all tokens drained from one EOA, several accounts under the same wallet affected, only the exchange balance withdrawn, NFT permissions abused, or recurring attacker addresses. This narrows but does not alone determine the cause.

Question 6 — Where did the funds go? Only after the initial mechanism is understood should the investigation move to transaction tracing — intermediary wallets, swaps, bridges, exchanges, fund splitting, and consolidation. For mapping where stolen funds moved after the initial theft, AMLBot's automated tool for tracing stolen crypto transactions can follow the visible money trail across wallets, bridges, and supported blockchains. AI Tracer reconstructs downstream fund movement from a transaction ID — it does not determine whether the original loss was caused by a stolen key, a malicious approval, social engineering, or address poisoning.

The Diagnosis Changes What Evidence and Response Matter Next

Once the initial loss mechanism has been identified, the victim still needs to decide what to do after crypto has been stolen — including preserving evidence, securing remaining assets, reporting the incident, and preparing for tracing or recovery efforts.

1. Private-key or Seed Compromise. Priority: assume affected key material may no longer be trustworthy. Determine whether one account or the broader seed-derived wallet may be affected. Preserve suspicious TxIDs. Secure any remaining assets using uncompromised wallet infrastructure. Investigate the source of compromise separately. Do not simply "change the wallet password" — a wallet application password is not necessarily what controls blockchain assets if the attacker has the private key or seed.
2. Malicious Approval or Drainer. Priority: identify the spender and the scope of the permission. Inspect remaining approvals. Revoke malicious permissions where technically appropriate. Determine whether the wallet secrets themselves also appear compromised. Trace assets already moved. Revoking an approval does not recover funds already transferred.
3. Scam-induced Transfer. Priority evidence: payment TxIDs, recipient addresses, chats, fake platforms, invoices or payment instructions, scammer identities, dates, and subsequent payment requests. The investigation then becomes destination attribution, downstream tracing, links to other scam victims, exchange endpoints, and OSINT.
4. Address Poisoning. Priority evidence: the legitimate destination, the poisoning address, the poisoning transaction, the mistaken outgoing transaction, the transaction chronology, and the business or payment workflow.
5. Exchange Account Takeover. Priority: lock the platform account. Preserve withdrawal details, login and device information. Contact the exchange through official channels. Obtain the transaction hash. Trace the destination after withdrawal.
6. When the mechanism is still unknown. Do not force a classification. A professional conclusion can legitimately state: the available blockchain evidence confirms an unauthorized transfer and subsequent fund movement, but does not establish the initial compromise vector; additional device, account, or communication evidence is required. That is stronger forensic work than inventing certainty.

Conclusion

Where the funds went and how they left are two different forensic questions. The blockchain is exceptionally good at preserving the movement. Identifying the cause requires knowing exactly which parts of the answer are on-chain — and which are not.

FAQ