Tracing Crypto Attacks: Best Practices for On-Chain Incident Response

BlogDeep Dive
Written By Henry Beaudin

written by: Lorenzo Zen

Introduction

Blockchain and cryptocurrency platforms face unique security challenges, with frequent hacks, fraud and exploits targeting exchanges, DeFi protocols or wallets. Unlike traditional cyber incidents, on-chain attacks can result in irreversible fund transfers within minutes, making rapid response critical. Effective incident response (IR) in the crypto space builds on proven cybersecurity principles but adapts them to on-chain realities. The goal is to limit financial loss, reduce downtime and maintain stakeholders' trust. 


A robust crypto IR program operates continuously – with plans, trained teams, and tools ready before an attack occurs.


Below, we outline general best practices, structured workflows, key team roles, industry frameworks, and real-world case studies to illustrate how to handle blockchain incidents in a clear, organized manner. 

General Principles

Preparation and speed are paramount: because stolen crypto can be laundered through thousands of addresses and mixers quickly, the window for recovery is narrow. Having a response strategy in place beforehand greatly increases the odds of containment and asset recovery. Rapid reaction – ideally within minutes of detection – is essential; any delay gives attackers a head start to dissipate funds . 

Equally important is assembling the right expertise and tools. Responders should be proficient in blockchain analytics and have access to tracing tools to follow complex on-chain money trails. 

Adaptability is key, as attackers constantly evolve tactics – teams must be ready to learn and pivot in real-time during an incident. 

Strong networks and communication channels with exchanges, miners/validators and law enforcement enable collaborative actions like freezing stolen assets before they leave a platform. If alerted in time, Crypto ISAC can help put you in contact with the relevant organizations. 

Finally, experience and lessons from past cases inform better decision-making in new incidents : organizations that practice IR (or work with experienced partners) can recognize attacker patterns and known exploits faster. In summary, crypto IR should be proactive (prepared), fast, skilled, collaborative, and iterative. This foundation supports the structured workflow described next. 

Structured Incident Response Workflow

Preparation and Planning

  • Incident Response Plan & Team: Before any incident, develop a detailed IR plan and designate an incident response team with defined roles and escalation paths. The plan should cover how to handle various crypto-specific scenarios and be regularly updated. For example, a basic plan includes identifying the IR team (with key members and responsibilities), establishing official communication channels to reach users (e.g. Twitter, Discord, Medium,…) and addressing legal/regulatory actions that may be required . Clearly list contact information for key personnel, blockchain analytics partners, potential law enforcement liaisons and any info-sharing programs you belong to (like Crypto ISAC).

  • Threat Modeling & Preventive Measures: A strong preparation step is to conduct threat modeling of your blockchain application or exchange. Identify likely attack vectors and critical assets (e.g. smart contract vulnerabilities, private key compromise, insider threats) . This helps prioritize defensive measures and plan specific responses. Playbooks can be created for common incident types (e.g. exchange hot wallet breach, smart contract exploit, private keys theft, …) detailing the exact steps to take. Many crypto organizations also set up emergency mechanisms in advance: for instance, deploying pause or kill-switch functions in smart contracts that can halt operations during an emergency or having an alternate multisig wallet ready to move funds if a primary wallet is compromised. Preparing these technical contingencies ahead of time enables faster mitigation during an attack. 

  • Tools & Access: Ensure the IR team has access to necessary tools and data. This includes blockchain intelligence and analytics platforms, monitoring systems, forensic tools for log analysis and communication tools for a “war room”. If internal tools or capacity are limited, teams should maintain an up-to-date list of vetted incident response vendors or blockchain intelligence and security firms (with emergency contact info) to engage rapidly during a crisis. 

Detection and Identification

  • Monitoring and Alerts: Early detection is critical. Continuous monitoring of on-chain activity and system logs should be in place to spot signs of an incident. Without proper threat detection, a protocol might only find out it was hacked after funds are gone or from third-party reports on social media. Exchanges should monitor for unusual login locations, mass withdrawals, disabled security controls, etc.

  • Incident Identification: When an alert triggers, the IR team should quickly triage and confirm if it’s a real incident. Identify what is being attacked (which contract, wallet, system) and how far it has progressed. This may involve checking multiple data sources: transaction records on relevant blockchains, server logs, etc.. Determine the scope: which assets are affected, how much is at risk or already lost, and whether the incident is still ongoing. Swift identification of the affected components guides the next steps. For example, in a hack it’s imperative to recognize an attack in progress and its entry point as soon as possible to enable timely containment . If really needed, put the system in a holding pattern while confirming the incident.

  • Severity Assessment: Along with identification, assess the severity/impact on every level: financial, reputational, regulatory, etc.. In crypto, even a small window can lead to large losses, so generally err on the side of high severity until proven otherwise. However, knowing if an attack is limited (e.g. only one token contract exploited for moderate funds) vs systemic (e.g. exchange-wide key compromise) helps allocate the right level of response. Most organizations define severity levels in their IR plan with criteria for each and this triggers predefined actions.

Containment and Mitigation

  • Isolate Affected Systems: Once an incident is confirmed, immediate containment is the top priority to stop any further damage. This often means freezing or isolating compromised components. For a centralized exchange breach, this could entail suspending withdrawals/deposits platform-wide or just on affected wallets and blockchain . For smart contract exploits, containment might involve pausing the smart contracts or specific functionalities if a pause feature exists . If no pause is available, other mitigations include rapidly adjusting parameters (like setting token transfer limits to zero, or lowering withdrawal caps) to hinder the attacker. Disconnecting compromised servers or wallets from the network is also crucial – e.g. revoke API keys or access tokens that were exploited. In all cases, move quickly to cut off the attacker’s access and prevent the incident from escalating 

  • Secure Unaffected Assets: In tandem, secure any assets or systems not yet compromised but at risk. For example, an exchange might move remaining funds from a hot wallet to cold storage if the hot wallet was breached. A DeFi project might instruct users to avoid interacting with the protocol or revoke token approvals, to contain the impact. It’s also advisable to increase monitoring on related systems at this stage, as some attacks (especially by advanced persistent threats like Lazarus Group) may be accompanied by secondary exploits or diversions

  • Law Enforcement and Legal Actions: While the situation is being contained, loop in the legal and compliance team. They should begin notifying relevant authorities and preparing any legal measures. At the same time, contact law enforcement as soon as possible. Providing them early information can set recovery efforts in motion. Preserve all evidence during containment (logs, blockchain transaction IDs, hacker messages) as this will be vital for any investigation and potential prosecution. Contacting law enforcement also ensures that any containment actions (such as accessing user accounts or freezing funds) are done in compliance with regulations and the platform’s terms of service.

  • Engage Help for Containment: The crypto community often has external helpers for containment. It’s beneficial to reach out to partners and even volunteer groups. For instance, community white-hat responders (such as the SEAL 911 group) actively assist protocols during live exploits to mitigate losses. They might exploit the same vulnerability to drain funds to a safe location before the black-hat does (with the intention of returning funds later). If such a community exists for your ecosystem, alert them. Additionally, many blockchain analytics firms and incident response services operate 24/7 hotlines: contacting them immediately can enlist expert help in tracking and freezing assets across exchanges. In rare cases, law enforcement cyber units might also be able to coordinate with miners or validators.

Funds Tracing

One of the most critical and time-sensitive components of on-chain incident response is tracing the movement of stolen or suspicious funds. Whether funds were drained from a smart contract, siphoned out of a hot wallet, or stolen via phishing, the sooner tracing begins, the higher the chances of recovery or disruption. In many cases, on-chain fund tracing runs in parallel with containment and can directly inform recovery and legal actions.

  • When to Start Tracing: Immediately after containment starts. As soon as attacker addresses are identified, initiate real-time monitoring of fund movements. If containment is still ongoing (e.g., a smart contract is actively being drained), tracing may help predict the attacker's next moves or identify other assets at risk. Fund tracing should not wait until post-incident investigation: start as soon as you have actionable on-chain intel.

  • Key Objectives: The primary objective of fund tracing is to identify the destination addresses and wallets, with a focus on locating collaborative exchanges or services that may be able to freeze assets before they are moved further. It is possible that protocols managing tokens (like stablecoins) might freeze assets or blacklist addresses. All identified addresses should be promptly flagged and reported to relevant law enforcement agencies, centralized exchanges, compliance teams, and legal counsel to maximize the chances of freezing and recovering stolen assets. Additionally, identifying attacker addresses can support public messaging efforts, enabling the broader community to assist in tracking and monitoring.

Tracing Tools

Most blockchains allow users full visibility over all the executed transactions. This level of visibility has to be paired with the best tools to be able to interpret the data.

Block Explorers

There are plenty of blockchain explorers that allow to search the blockchain:

Free(mium) tracing tools

Commercial tracing tools

Blockchain data analytics

Tracing Tips and Tricks

Multiple platform

Different tracing platforms often use varying heuristics, wallet labels, and interface designs. Using multiple tools in parallel provides a more holistic view and helps cross-validate information for greater accuracy. Don’t overlook open-source tools—when combined with enterprise-grade platforms, they can offer valuable complementary insights, especially for early-stage triage or niche use cases.

Monitoring for Off-Ramps and Engaging Exchanges

The primary objective of fund tracing is always the prompt freezing and potential seizure of stolen assets. To achieve this, tracing efforts should focus on identifying deposit addresses linked to centralized services, such as exchanges, payment processors, gambling platforms, and similar custodial entities. These intermediaries are typically in a position to proactively freeze assets associated with illicit activity and may return funds when presented with the appropriate legal orders or court injunctions.

Most commercial tracing tools offer comprehensive coverage of centralized services and can accurately identify full address clusters associated with exchanges, payment processors, and other custodial platforms. However, it’s important to understand how to recognize these services manually on-chain, especially in cases where you don’t have access to commercial tools or when the platforms return only unlabeled or partially labeled addresses.

When specialized tracing tools aren’t available, you can still identify likely exchange or other centralized service wallets by spotting telltale on-chain patterns. Even without labels, large-scale fund movements and repetitive behaviors can reveal the presence of an exchange, custodian, or mixer. Below are practical heuristics to recognize centralized services on-chain, useful for tracing stolen funds in an incident response scenario:

  • Large Unlabeled Address Clusters: Look for unusually large clusters of addresses that appear linked together (e.g. via co-spending in one transaction). If an address is part of a cluster of hundreds or thousands of addresses, it’s likely controlled by a big centralized entity. Regular users or small groups don’t typically manage so many addresses, so a huge unlabelled cluster often points to an exchange, payment processor, or other service handling many accounts at once.

  • Deposit Addresses and Consolidation Patterns: Centralized services usually give each user a unique deposit address and then sweep those funds into a main wallet. You can trace this by observing addresses that only receive funds and then quickly forward nearly the entire balance to a single “core” address. For example, if you see multiple different addresses each receiving crypto and then sending all those funds (minus a tiny fee) to the same destination, that destination is likely a central hot wallet or collection address for an exchange. Following these trails of one-way deposits leading into a common wallet helps identify the service’s core wallet even without an official label.

  • Volume and variety of counterparties: A centralized service’s main wallets will handle high volume and diverse counterparties. If one wallet is receiving funds from a wide range of unrelated addresses and sending out to just as many, it’s more likely an exchange or mixer than a personal wallet. By contrast, personal wallets usually have a narrower set of contacts.

  • Batch Transactions and Consolidations: on Bitcoin and other UTXO chains, centralized services often consolidate and batch transactions to manage many inputs and outputs efficiently. Transactions with “many to one”, “one to many” or “many to many” patterns are likely typical of services handling lots of user withdrawal requests in one go.

  • Fee funding on Ethereum and EVM chains: On Ethereum and other account-based blockchains, centralized services exhibit different clues. Deposit addresses that receive tokens on these chains often receive a small top-up of the native coin (ETH, BNB, etc.) for gas fees, then forward tokens onwards.

  • No interactions with smart contracts: Unlike individual users, these deposit addresses usually don’t engage in other DeFi or contract interactions. If an address’s only purpose seems to be collecting and relaying funds, it points to an exchange or custodial service pipeline.

Do not trace through centralised services

Identifying centralized services, as outlined in the previous section, is critical for another reason: knowing when to stop tracing funds on-chain.

Imagine you walk into a bank branch and deposit a $100 bill. It’s impossible to know what happens to that exact bill afterward—it may be used to pay another customer, and when you return to withdraw $100 a month later, you likely won’t receive the same note, or even the same denominations. The same concept applies to centralized services.

They are called centralized for a reason: they own the private keys of the deposit addresses they assign to users. These addresses are essentially on-loan for the purpose of making a deposit, but once the funds arrive, the service takes full control. As explained earlier, they may consolidate those funds into a main wallet or redistribute them to fulfill withdrawals for other users.

Once funds enter a centralized exchange or service, on-chain tracing becomes ineffective and often meaningless. What happens inside the platform (whether the funds are swapped, withdrawn, still sitting idle, or linked to a specific user) is off-chain information that only the service provider can access.

This is where law enforcement agencies (LEAs) come into play. They are the only entities that can serve a subpoena, court order, or equivalent legal request to obtain internal records from the service, such as account ownership, transaction history, or wallet activity. In some cases, LE intervention may not even be necessary: certain compliant services (like crypto-to-crypto swap platforms that do not require KYC) may voluntarily cooperate and share relevant information, so long as it doesn’t violate data protection laws.

In short: do not attempt to trace funds through centralized services, even if they are not labelled or associated with a known entity. Once you've identified that the trail leads to one, your next step is to escalate through legal channels or coordinated industry response, not to continue tracing blindly beyond that point.

Monitor chain-hopping

Chain-hopping refers to moving crypto funds between different blockchains (chains) in order to obscure their origin . Attackers exploit cross-chain bridges, swaps, and decentralized exchanges (DEXs) to “hop” from one blockchain to another, frustrating investigators who might be tracing funds on a single chain. By converting assets and jumping across networks, criminals can evade the reach of exchange compliance checks and traditional blockchain analytics, which often focus on one chain at a time . This tactic has become a fast-growing money laundering typology.

In short, chain-hopping is now a go-to move for sophisticated hackers seeking to lose pursuers by breaking the transaction trail across networks.

How Attackers Use Cross-Chain Bridges: Cross-chain bridges are services (often smart contracts or networks of nodes) that lock assets on one blockchain and mint equivalent tokens on another, enabling transfer of value between chains . For example, moving Ether from Ethereum to Solana via a bridge would involve locking the ETH in an Ethereum bridge contract and minting “wrapped ETH” on Solana. Later, the wrapped asset can be burned on Solana to release the original ETH on Ethereum.

Attackers leverage this mechanism by taking stolen funds on one chain, swapping or wrapping them, and then bridging to a new chain where the funds emerge as new tokens in the same or a fresh address. This breaks the direct on-chain link between the original crime and the funds’ new location. Notably, hackers increasingly turned to bridges after some mixers were sanctioned (for instance, North Korea’s Lazarus Group has laundered huge sums via cross-chain routes like RenBridge, THORChain, and the Avalanche Bridge).

By moving through bridges and even converting tokens to privacy-focused coins on the new chain, criminals attempt to sever tracing continuity.

Identifying Chain-Hopping: detecting when funds leave one blockchain for another is challenging but doable with careful observation. Here are practical indicators and steps:

  • Watch for Known Bridge Interactions: If the funds you’re tracing suddenly go into a known bridge contract or address, that’s a strong sign of a chain-hop. Many bridges use identifiable smart contracts (for example, deposits into the RenBridge contract or other bridge routers). Unusual transactions that lock tokens without an obvious onward transfer on the same chain often indicate the assets were locked for bridging. Keep an eye out for transactions calling bridge functions (e.g. deposit or lock) or sending funds to bridge addresses.

  • Token Swaps and Wrapping/Unwrapping: Before hopping chains, attackers often swap into assets that are easy to move. A common tactic is converting various stolen tokens into one major cryptocurrency or stablecoin (e.g. swapping everything for ETH or USDT on a DEX). This consolidation makes it easier to bridge in one go. Likewise, wrapping tokens can be a telltale sign – if you see an asset converted into a wrapped version (like WETH, renBTC, or other wrapped coins), the next step might be a cross-chain transfer. Wrapping ETH into an ERC-20 or minting renBTC (a Bitcoin-pegged token on Ethereum) often precedes moving value to another chain or to Bitcoin. Conversely, unwrapping (burning a wrapped token) could indicate the asset has exited a bridge on the target chain.

  • Timing and Corresponding Amounts: When a chain-hop is suspected, check public data on the target chain for a corresponding incoming transaction. Often, after funds leave Chain A (e.g. locked in a bridge), they will appear on Chain B within minutes or hours. The incoming amount on Chain B (minus fees) will match what was locked. For example, if 100 ETH was sent into a bridge contract on Ethereum, did a new address on Avalanche or BSC receive ~100 ETH (as wrapped ETH) around the same time? If you identify a candidate address on the destination chain, verify that its first incoming transaction comes from a bridge-related address or token contract.

  • Identify Output chain and address: In many smart contract-based bridges, the bridge transaction on the source chain includes calldata or emitted event logs that contain metadata such as the destination chain ID and the recipient address on the target chain. This information can often be extracted by decoding the transaction input or inspecting the logs, especially on EVM-compatible chains where standard ABI decoding applies. While the output address is often the same as the sender, bridges frequently allow users to specify a different recipient address on the destination chain, which is critical to identify early in the trace. Extracting this metadata enables investigators to preemptively locate the destination address before the bridged funds appear, significantly narrowing the search window and improving cross-chain correlation.

  • Common Cross-Chain Platforms: Be aware of the typical services criminals use. Third party bridges like LayerZero, ThorChain, Across, Hyperliquid, and Portal/Wormhole have all been used to launder funds. If your trace leads to one of these services, assume the funds are changing chains. Each has distinct on-chain footprints: for instance, ThorChain can swap native assets across chains (e.g. ETH to BTC) without a centralized exchange, so a deposit into ThorChain’s pool contract might result in native BTC output to a BTC address . Recognizing the platform will tell you which new chain or currency to inspect next.

Tools and Techniques for Cross-Chain Tracing: Tracing funds across chains may require pivoting to new tools. Traditional blockchain explorers are chain-specific, so once a hop occurs you’ll need an explorer for the target chain (e.g. a Polygon explorer if funds moved to Polygon). Specialized blockchain analytic platforms now offer automated cross-chain tracing that can follow common bridge hops in one interface. If you have access to such a tool, use it to your advantage: it will save time by linking addresses across chains and visualizing the flow. If not, a manual approach involves note-taking and parallel tracking: document the transaction hash of the bridge deposit, then search the target chain for any transaction that corresponds (some bridges publish references or have block explorers of their own).

In cases where the trail goes to Bitcoin (from an Ethereum-based theft, for example), you might find a bridge transaction on Ethereum that mentions a BTC address (some bridges log the destination address). From there, switch to a Bitcoin explorer and continue tracing from that BTC address forward. Each time you switch chains, pause and reorient your investigation – ensure you understand how the specific bridge operates (lock-mint, swap, etc.) so you know what to look for on the other side.

It’s important to remain organized: label the point of chain-hop in your notes or tracing software, and start a new thread for the next chain. Expect additional hops – sophisticated launders may bounce through multiple networks in succession (Ethereum to BSC to Tron, for example). Each hop may require you to pause, find the next path, and resume. If at any point the trail becomes too convoluted (e.g. multiple simultaneous hops or very obscure chains), consider seeking expert assistance or more advanced tools.

The key is not to panic: chain-hopping is challenging, but by methodically following the money onto each new platform, you can maintain the trace. Remember that criminals rely on investigators giving up at hops.

Engaging with mixers and “demixing” attempts

When stolen crypto flows into a mixing service (mixer), investigators face one of the toughest challenges in tracing. Crypto mixers (also called tumblers) are services that aggregate and shuffle funds from many users, then distribute them such that each user gets back the same total value, but from a mix of sources.

The effect is to break the traceable link between incoming and outgoing funds. In simple terms, a mixer acts like a black box: hackers deposit their stolen coins into the box along with others’ coins, and later withdraw funds that appear unrelated to the original dirty input.

Because mixers conceal the origin of crypto transactions so effectively, they are a favored laundering tool for criminals seeking anonymity. At the same time, some regular users employ mixers for privacy reasons, which means not every use of a mixer is criminal, a fact investigators must keep in mind to avoid false accusations.

Why Mixers Matter in Laundering: Mixers play a critical role in the later stages of crypto money-laundering, typically during the “layering” phase where criminals try to scrub any link between funds and illicit origins. For incident responders, encountering a mixer usually means the trail has hit an anonymizing wall, but there are still steps you can take to glean clues and respond intelligently.

Identifying Mixer Activity On-Chain: Early detection of mixer usage is crucial. You want to recognize that funds have entered a mixer as soon as possible, so you don’t waste time trying to follow them through that black box. Here are best practices for spotting mixer involvement:

  • Recognize Mixer Addresses and Contracts: Some mixers are well-known and have publicly identifiable addresses or contracts. For instance, Tornado Cash on Ethereum is a smart contract with fixed deposit addresses for different coin amounts (0.1 ETH, 1 ETH, 10 ETH, 100 ETH pools). If you see a suspicious address sending exactly 100 ETH to an Ethereum contract, check if that contract is Tornado Cash (most explorers have all Tornado Cash addresses labelled). Similarly on Bitcoin, mixers like Wasabi or Samourai’s Whirlpool use CoinJoin transactions which have multiple inputs and equal-sized outputs; blockchain analytics tools often flag these. If your traced funds suddenly get split into many transactions with round-number amounts or go to addresses that have a history of mixing, consider it a mixer. Tag the mixer deposit in your notes (“Funds enter Tornado Cash at this point”) as this marks the end of straightforward tracing.

  • Mixers’ On-Chain Fingerprints: Mixers often impose certain patterns. In Ethereum mixers, one common fingerprint is time and amount consistency. For example, on Bitcoin, look for transactions that have a large number of inputs and outputs of equal value (typical of CoinJoin mixers). If the tracing path suddenly becomes disordered, fragmented, or nonsensical, it's a strong indicator that you've entered the output phase of a mixer or a peeling chain from a custodial service. This often presents as a sequence of seemingly random payments — varying amounts sent to addresses with no discernible link, some of which may have been used in the past or are reused across unrelated flows. In such cases, it's possible that the original suspect deposited funds into an unrecognized mixing service, and what you're seeing is the post-mix distribution to other users. These outputs are rarely attributable to the original input and typically represent a point where direct tracing loses its meaning. When the transaction logic breaks down like this, it’s a good moment to pause, reconsider the narrative, and assess whether you’ve reached the operational boundary of a black-box service like a mixer or an exchange withdrawal queue.

Post-Mix Tracing: Once funds are inside a mixer, direct tracing pauses: you cannot deterministically link a given input to any specific output. However, not all hope is lost. Skilled investigators look for post-mix behavioral patterns that might reconnect to the perpetrator. Here are some heuristics and clues to monitor after mixer usage:

  • Withdrawal Analysis: Examine how funds exit the mixer. Are they withdrawn in a similar pattern to how they went in (same chunk sizes, or perhaps all at once)? Many mixers allow users to withdraw to whatever address they want. If you notice that multiple withdrawals from the mixer all go to a single new address, that’s a potential slip by the launderer: it could mean the same person is collecting their outputs and recombining them. For example, if 10 deposits of 10 ETH went into Tornado and then over time you see an address receive ten 10 ETH incoming transactions from Tornado’s pool, that’s a strong hint that this address belongs to the original thief regrouping their money. Such a pattern effectively undoes the anonymity gained, because while you can’t prove which 10 ETH came from which deposit, seeing one address get them all back is a smoking gun of common ownership.

  • Timing Correlations: Mixers often encourage users to wait before withdrawing (to increase ambiguity), but not everyone waits long. Investigators can sometimes correlate a specific deposit and withdrawal if the user was careless. If a large deposit entered a mixer and just 5 minutes later a similar amount came out to a fresh address, it’s likely (though not certain) the same user cycling funds quickly. By itself, timing isn’t proof, but it can narrow suspects. Advanced analysis can use statistical correlation: for example, if an attacker splits funds into three deposits and then exactly those three amounts come out together after a similar delay, that combination might be uniquely identifying. Academic research on Tornado Cash has shown that user behavior (like preferred withdrawal intervals) can slightly reduce anonymity by linking addresses probabilistically . As a responder, you can note these coincidences as leads (e.g., “withdrawal at 12:05 UTC of 100 ETH may correspond to attacker deposit at 11:55 UTC of 100 ETH”) and focus on the withdrawal address as suspicious.

  • Reused Wallets or Slip-Ups: Sometimes criminals make mistakes. A classic one is reusing an address that was already linked to them. Suppose an attacker sends stolen coins into a mixer, and later withdraws to one of their old wallets (maybe by accident or convenience). If that old wallet was watched or labeled (say it interacted with an exchange account or was involved earlier in the hack), you instantly regain the trail. Always compare post-mix output addresses against any known addresses from the pre-mix part of your investigation or any attributed addresses. Another slip-up is interacting with identifiable services too soon after mixing (e.g., the hacker withdraws from the mixer and immediately sends the funds to a well-known exchange). Investigators have had success when hackers, after mixing, deposit funds to a centralized exchange (CEX); the exchange, if alerted, can freeze funds or provide KYC info. So monitor where the mixer outputs go: if you see a suspicious output address sending to a major exchange or a recognizable service, that’s a lead. Even if you can’t get the identity yourself, you can alert that exchange or law enforcement to that address.

  • Secondary Clustering: In some cases, you can use clustering heuristics on the outputs. For example, on Bitcoin, if two different output addresses from a mixer later participate in the same transaction as inputs, you know those outputs have now merged (common ownership), effectively demixing themselves. This is known as the common spend heuristic (if two coins get combined, they must have a common owner). So if you’re monitoring a set of addresses that withdrew from a mixer, watch for any of them consolidating. On Ethereum, if the launderer withdraws to multiple addresses and then those addresses all interact with the same smart contract or transfer funds to one another, that links them. Any post-mix interaction between two outputs is a gold nugget of information. It’s worth setting up alerts on likely output addresses (if you can guess which ones are likely the criminal’s) so you catch if they eventually converge or reveal themselves.

It's important to understand that mixer behavior is highly unpredictable, and attempts to demix or correlate inputs and outputs are often based on probabilistic models, not certainties. While some analytics tools or researchers may surface “likely” post-mix flows, these results should always be treated as leads, not facts. Blindly pursuing every potential mixer output can quickly spiral into chasing ghosts: you may waste significant time on false positives and risk flooding your investigation with so many branches that none are actionable. If the post-mix picture is unclear or unverifiable, it’s best to pause and prioritize, rather than dilute the investigation’s focus. In cases where mixer outputs are ambiguous or the stakes are high, it is strongly recommended to escalate to specialist blockchain intelligence firms or law enforcement agencies who may have access to additional heuristics, off-chain intelligence, or subpoena power. Knowing when to hand off the lead is just as important as knowing when to pursue it.

Best practices

  • Set real-time alerts: it is of utmost importance that you actively monitor all the involved addresses with real-time alerts. This includes the original attacker’s addresses, but also all those found down the line where the funds could still be unspent. This allows maximum efficiency in the response in case funds move to a service that can freeze them.

  • Always work on a graph: keep track of your work on your preferred graphing tool (most commercial products have an integrated graphing functionality, but there are open-source options available too), while working on your preferred tool(s). Keep the graph on one side and the other explorers on the other, then don’t forget to update the graph with allyour findings.

  • Share monitored addresses: Keep an updated list of monitored addresses to share with the community or key stakeholders. Take advantage of industry networks (like the Crypto Defenders Alliance) to circulate the information within the relevant organisations.

Investigation & Eradication

Once the immediate threat is stopped, the team shifts to understanding and eliminating the root cause.

  • Incident Analysis: Conduct a thorough investigation of how the breach or exploit occurred. This might involve on-chain analysis (tracing the attacker’s transactions to understand the flow and methods), off-chain forensics (examining server logs, malware analysis if an internal system was compromised, etc.), and code review (if a smart contract was exploited, identify the vulnerability). A forensic analyst on the team should lead evidence collection and timeline reconstruction . Determine which vulnerabilities or security failures allowed the incident: e.g. an unpatched software, a leaked private key, a smart contract bug in a specific function, or a social engineering attack on an employee. If the analysis is not possible with internal resources, this step should be outsourced to the most relevant company.

  • Eradication of Vulnerability: Fix the root cause before resuming operations. In a smart contract exploit, this could mean patching the contract (if upgradable) or deploying a new contract version that removes the vulnerability. In a platform hack, it may mean closing backdoors, removing malware, or upgrading compromised infrastructure. For example, after a hack caused by leaked API keys, an exchange would reset all API keys and implement stricter key management. Rotate credentials or keys that were exposed - e.g. if an admin private key was compromised, cease its use and move assets to new secure wallets. The goal is to ensure the attacker (or others) cannot repeat the attack. In parallel, continue tracking the attacker’s on-chain movements for fund recovery purposes (this is more a recovery task, but deeply linked to investigation findings).

  • Upgrade Security Controls: As part of eradication, take the opportunity to harden systems: after identifying how the hack evaded existing checks, implement additional controls or alerts.

  • Documentation: Throughout investigation, document everything. This helps in the post-incident review and provides a record for insurance or legal purposes. A timeline of events, actions taken, and findings should be compiled by the IR manager or a designated incident scribe. Documentation is also important if you will share a public incident report later for transparency.

Recovery and Restoration

  • Restoring Operations: With the threat addressed, focus on safely restoring normal operations. For exchanges or custodial services, this means reopening trading, withdrawals, deposits that may have been halted, but only once confident that systems are secure . It’s wise to do this gradually: e.g. re-enable logins first, then deposits, then withdrawals last. For smart contract platforms, un-pause the protocol or deploy the fixed contracts, and possibly run a third-party audit of the changes to reassure users.

  • User Communications & Support: As systems come back, provide clear instructions to users. If they need to take action (like resetting passwords, revoking token approvals, or migrating to new contract addresses), guide them through it. Maintain open channels for user support: incidents often generate user anxiety, so having your support team or community moderators available to answer questions is part of incident recovery. Transparency here helps rebuild trust (more on communication in a dedicated section below).

  • Fund Recovery Efforts: If funds were stolen, work on recovering what’s possible. By this stage, blockchain analysis experts should be tracing the stolen assets. Often, stolen crypto flows to exchanges or mixers. As highlighted before, collaborate with exchanges to freeze any deposits from the attacker’s addresses . Even if full recovery is rare, any percentage returned is a win for users.

  • Reimbursement and Insurance: Prepare a plan to compensate affected users for unrecovered losses, if feasible. Top exchanges and DeFi platforms often reimburse users through insurance funds or treasury reserves in order to restore confidence. While not strictly “response” (more of a business decision), having this plan decided early in the recovery process is important for reputation management.

Communication (Internal and External)

Effective communication is a thread that runs through all IR phases. It’s highlighted here as a dedicated step because managing information and stakeholder expectations during a crypto incident is vital.

  • Internal Communication: Right as an incident is identified, initiate an internal alert. The incident response lead should activate the war room and pull in all relevant team members (security engineers, developers, ops, legal, PR, management as needed) to a single channel or room to coordinate . Keep a steady flow of updates within this team as new information comes. Clear role assignment (decided in preparation) prevents confusion: e.g., one person coordinates technical response, another handles external messaging, another liaises with law enforcement, etc. Document decisions and ensure everyone is aligned on the current status and next steps throughout the event.

  • Public Communication: Be transparent and timely with users and the public. In crypto, users often detect something is wrong quickly (funds stuck, on-chain data visible), so acknowledge the incident early to control the narrative. Put out an initial statement on official channels confirming awareness of the issue, and perhaps initial instructions. Utilize all relevant channels: an official blog or website notice, Twitter and Telegram announcements, Discord messages, etc., to reach the community quickly in real-time. Provide updates as you learn more: even if small, regular updates help reassure users that the team is actively working on it.

  • Message Content: Strive for a balance of transparency and security. Explain what happened in general terms, what actions are being taken, and what users should do on their end (if anything). However, avoid disclosing sensitive details that could help the attacker or spark copycat attacks. Also, communicate what you don’t yet know and that an investigation is ongoing – this honesty prevents misinformation. Importantly, reassure users about funds when possible.

  • Media and PR: Significant breaches will draw media attention. It’s wise to prepare a press release or at least a media statement once facts are clearer . Appoint a spokesperson (often the CEO or CISO) to handle interviews if needed. If law enforcement is involved, coordinate on what information can be shared.

  • Post-Incident Disclosure: After the dust settles, consider publishing a post-mortem report for the community. This typically includes a summary of what happened, how it was resolved, and lessons learned/improvements that will be made. This level of transparency is common in the crypto industry and can turn a negative incident into a learning experience that increases community confidence.

Post-Incident Analysis and Lessons Learned

No incident response is complete without a retrospective. Once operations are back to normal, convene the team for a post-incident review (or “lessons learned” session). The aim is to analyze what went well and what can be improved in both the security controls and the incident handling process.

  • Root Cause Review: Ensure the root cause is well-understood and documented. Identify any gaps in defenses that allowed the incident. IR Process Evaluation: Critically assess the response timeline (e.g., how fast was detection, was containment efficient, were roles clear, did communication flow well? Gather metrics if possible to quantify performance. If certain steps lagged, update the IR plan to address those. Possibly revise team roles or provide additional training where needed.

  • Improvements & Follow-ups: Implement the improvements identified. This may involve code fixes (beyond the immediate patch), infrastructure upgrades, policy changes, or all of the above. Testing the IR plan is also an improvement: run simulated incidents (war-game exercises) to practice and refine procedures.

  • Knowledge Sharing: Finally, share relevant lessons with the broader community if appropriate. The blockchain ecosystem benefits when teams disclose vulnerabilities and attack patterns (responsibly) so others can protect themselves. Contribute to industry best practices: many organizations publish post-mortems or speak at conferences about how they handled incidents, which collectively raises the security bar.

Conclusion

Handling blockchain and cryptocurrency incidents requires a blend of traditional incident response discipline and crypto-specific tactics. By establishing clear workflows, practicing them, and assigning dedicated roles, teams can respond to breaches, hacks, fraud, or exploits in a calm, organized manner despite the high stakes. Key best practices include thorough preparation (with plans, contacts, and tools ready), continuous monitoring for early detection, rapid containment using all available means (technical and collaborative), transparent communication to users and stakeholders, and diligent post-incident analysis to improve for the future. Importantly, the global and transparent nature of blockchains means that incident response is a collaborative effort: engaging the broader security community, other platforms, and law enforcement often makes the difference in recovery outcomes.

By learning from established frameworks and real incidents, crypto organizations can develop robust incident response playbooks that not only resolve crises effectively but also bolster the long-term security and trust in their platforms. With billions of dollars and the integrity of decentralized systems at stake, investing in incident response readiness is not optional: it’s a foundational pillar of operating safely in the blockchain industry. Each incident, whether in your own organization or observed elsewhere, is an opportunity to refine this craft and build a more secure crypto ecosystem moving forward.

Lorenzo Zen is a Blockchain Threat Intelligence Researcher at Crypto ISAC. He brings years of experience investigating fraud and crypto threats at Coinbase and Neutrino, with a background in digital forensics and on-chain analysis.

About Crypto ISAC

The Crypto ISAC is a member-driven, not-for-profit organization that works together to curb malicious actors, address vulnerabilities, share intelligence, and move security forward to protect the crypto ecosystem. We are founded by leading crypto organizations and designed for cryptosecurity experts to address the security and trust challenges that face crypto today and shape the crypto ecosystem of tomorrow.

Henry Beaudin
Next

Transaction Simulations: Enhancing Blockchain Security