Skip to content
Quantix Security Labs

Incident Response & Forensics

During an incident the first hours decide how much can be contained and what evidence survives. Quantix provides technical analysis to help teams understand what happened, how, and what can still be done. Engagement depends on availability at the time of request; response times are agreed per engagement and are not guaranteed through this website.

Technical analysis when something has already gone wrong.

Report an incidentIf funds are at risk now
Dark map of an incident: funds flowing from an exploited contract through wallets, a bridge and a mixer to exchange deposits, with a detect, contain, trace and recover timeline along the edge.

Service overview

Contain first, explain next, report last.

Technical support for the hours and days after an exploit, key compromise or suspicious transaction: what happened, what is still at risk, and what to do next.

The first hours of an incident are about decisions: what to pause, which keys to rotate, who to tell. The investigation that follows reconstructs every transaction, follows the funds and explains why the controls in place did not stop the attack.

We work alongside your team, not instead of it. Containment options are presented with their trade-offs for you to decide; tracing records why each address is attributed the way it is; the report is written for your engineers first and published only if you choose.

Incident support is subject to availability at the time of request. If you need agreed response commitments, they are set in writing during scoping, before anything happens.

Typical triggers
Exploits, key compromise, malicious upgrades, phishing campaigns
Your decisions
Containment, disclosure and publication remain yours
Availability
Subject to availability; no guaranteed response times

Applies to

  • Exploited or suspected-compromised contracts
  • Compromised keys and signing infrastructure
  • Frontend or DNS compromise
  • Bridge and cross-chain incidents
  • Governance and admin-key misuse
Transaction reconstructionFund-flow tracingRoot-cause analysisContainment planning

If funds are at risk right now

Six things to do before anyone else arrives.

These steps apply whether or not you engage Quantix. They protect what remains and preserve what an investigation will need.

  1. 1

    Contain what you can

    If your contracts have a pause, guardian or circuit breaker, use it. Revoke roles or approvals you know to be compromised. Take affected frontends offline if they may be serving malicious transactions.

  2. 2

    Preserve evidence

    Do not wipe or redeploy servers yet. Snapshot logs from frontends, APIs, RPC providers and CI. Export the chat threads where the incident was first discussed.

  3. 3

    Rotate exposed credentials

    From a clean machine, rotate keys and secrets that may be exposed: deployer and admin keys, API keys, CI secrets, DNS and hosting accounts.

  4. 4

    Keep the investigation private

    Coordinate in a closed channel with named participants. Warn users to stop interacting if the risk continues, but avoid publishing technical details before the attack path is understood.

  5. 5

    Start a timeline

    Write down what was noticed, when and by whom, and every action taken since. It will be the backbone of the investigation and the report.

  6. 6

    Contact the right parties

    Bring in your security partners, and the teams operating bridges or exchanges funds may flow through. Consider whether to involve law enforcement.

Quantix provides incident support subject to availability at the time of request. Response times are agreed per engagement and are not guaranteed through this website.

Threats addressed

The incidents we are asked to investigate.

Each class leaves a different trail on-chain and off-chain, and calls for different first steps.
  • Key compromise

    Admin or deployer key used by an attacker

    Roles transferred, implementations replaced or funds moved by a key that should have been safe.

  • Upgrade risk

    Malicious or faulty upgrade

    A proxy pointed at new logic that drains funds, disables checks or locks users out.

  • Oracle manipulation

    Price-driven exploit

    A pool or feed moved within a block to borrow against inflated collateral or liquidate healthy positions.

  • Flash-loan exploit

    Single-transaction drain

    Borrowed capital used to break an invariant and repaid in the same transaction, leaving a loss behind.

  • Bridge message validation

    Forged or replayed messages

    Funds released on one chain without a matching, valid deposit on the other.

  • Signature phishing

    User approvals drained

    A campaign that collects permits or approvals and sweeps balances from many holders.

  • Frontend supply chain

    Compromised interface

    A hijacked domain, CDN or dependency serving transactions to an attacker’s contracts.

  • Governance manipulation

    Hostile proposal

    Voting power accumulated or borrowed to pass a proposal that moves treasury funds or roles.

  • Liquidity risk

    Liquidity pulled

    Pool liquidity or reserves withdrawn by insiders, leaving holders unable to exit.

Technical capabilities

Every hop annotated, every assumption stated.

Forensic work is only useful if others can check it. Each capability produces evidence your team, your partners or the authorities can follow.

  • Transaction reconstruction

    Attack transactions decoded call by call, with state diffs and internal calls.

    • Traces and state diffs
    • Fork replay at the exploit block

  • On-chain tracing

    Funds followed across addresses, swaps and bridges, with every attribution reasoned.

    • Hop-by-hop annotation
    • Exit points per chain

  • Attack-path analysis

    Preconditions, the vulnerability, and the attacker’s exact sequence of actions.

    • Preparation transactions
    • Funding sources

  • Evidence preservation

    Logs, artefacts and communications secured with a record of who collected what, and when.

    • Hashes of collected files
    • Chain-of-custody log

  • Containment design

    Options to stop further loss, with what each costs and what it risks.

    • Pause, revoke, rotate
    • User communication

  • Root cause and reporting

    Why it happened, why controls missed it, and what changes.

    • Internal report
    • Optional public post-mortem
Illustrative fund-flow traceFunds leave an exploited contract through an attack contract, are split between an externally owned account that bridges them off the chain and a swap into a stablecoin that is consolidated at a further address.withdraw()40%60%deposittransferLending vaultexploited contractAttack contractdeployed in block n−2Attacker EOAcontract deployerDEX routerswap to stablecoinBridge depositleaves this chainFresh addressconsolidationcontinues on destination chain

Illustrative trace. Nodes are labelled by role; a real trace records the address, the transaction and the reasoning behind every attribution.

Assessment methodology

Eight steps in three windows.

The order matters. Early decisions protect remaining funds and evidence; analysis then reconstructs what happened; the report explains why, and what changes.
The seven-stage Quantix workflow
  1. 1First hoursSteps 01–03
  2. 2Following daysSteps 04–06
  3. 3After containmentSteps 07–08
  1. 01

    Initial triage

    Establish what is affected, whether the attack is ongoing, and which assets remain at risk.

  2. 02

    Evidence preservation

    Secure logs, deployment artefacts and communications before they are lost or overwritten.

  3. 03

    Containment recommendations

    Concrete options to stop further loss, with the trade-offs of each, for your team to decide.

  4. 04

    Transaction reconstruction

    Decode the attack transactions call by call, including state changes and internal calls.

  5. 05

    On-chain tracing

    Follow funds across addresses, swaps and bridges, and annotate where they leave the chain under analysis.

  6. 06

    Attack-path analysis

    Identify the precondition, the vulnerability and every step the attacker took to exploit it.

  7. 07

    Root-cause assessment

    Explain why the vulnerability existed and why existing controls did not stop it.

  8. 08

    Post-incident reporting

    A written report for your team, and a public version if you choose to publish one.

Tools & techniques

Reproducible analysis, from raw traces to a written timeline.

Every conclusion in an incident report can be re-derived from the transactions and artefacts it cites.
Tools and techniques used for Incident Response & Forensics
Tool or techniqueCategoryWhat it is used for
Foundry cast run / traceReconstructionReplays a transaction locally with full call trace and decoded calldata.
debug_traceTransaction, prestate tracerReconstructionInternal calls and exact state before and after each attack transaction.
Fork replay (anvil --fork-block-number)ValidationReproduces the exploit at the block it happened, and tests whether a proposed fix stops it.
Address graph analysisTracingBuilds the fund-flow graph across hops, swaps and bridges, with attribution notes per node.
Cross-chain message lookupsTracingMatches bridge deposits and releases across chains using each protocol’s message identifiers.
Verified source and ABI decodingAnalysisDecodes attacker and victim contracts; unverified bytecode is decompiled and annotated.
SHA-256 evidence manifestsEvidenceEvery collected log and artefact hashed and recorded with collector and time.
Incident timelineCoordinationSingle ordered record of observations, decisions and actions, shared with your team.

Ecosystem coverage

Technical depth per execution environment.

Tracing and reconstruction depend on each chain’s tracing support, finality and bridge infrastructure.

Ethereum

Layer 1, proof of stake EVM

Programming languages
SolidityVyperYul
Typical vulnerabilities
  • Reentrancy, including read-only reentrancy
  • Oracle and spot-price manipulation
  • Access control on privileged functions
  • Proxy storage collisions and initializer misuse
  • Signature replay across chains and contracts
  • Front-running and MEV exposure
Assessment methodologies
  • Line-by-line manual review
  • Invariant fuzzing (Foundry, Echidna)
  • Symbolic execution and formal verification
  • Economic attack modelling
Monitoring capabilities
  • Proxy admin and implementation changes
  • Governance proposals and timelock queues
  • Large transfers and treasury outflows
  • Oracle deviation against reference feeds
Supported standards
ERC-20ERC-721ERC-1155ERC-4626EIP-2612EIP-712ERC-1967ERC-4337

Ecosystems indicate technical specialisation only, not partnerships or endorsements.

Deliverables

What incident support covers, and what you receive.

Scope is agreed in the first conversation and revised as the picture becomes clearer. Every deliverable is written for your team first; publication is your decision.

  • Triage memo

    What is affected, what remains at risk, and the containment options with their trade-offs.

  • Transaction reconstruction

    Each attack transaction decoded, with state changes and the attacker’s preparation.

  • Fund-flow trace

    Annotated graph of where funds went, where they left the chain, and how each step was attributed.

  • Evidence manifest

    Hashed list of collected logs and artefacts with chain-of-custody notes.

  • Root-cause report

    The vulnerability, why controls did not stop it, and the changes recommended.

  • Post-mortem draft

    A public version for your review, published only with your approval.

Key assessment areas

  • Initial incident triage
  • Transaction reconstruction
  • On-chain fund tracing
  • Attack-path analysis
  • Evidence preservation
  • Containment recommendations
  • Root-cause assessment

Typical deliverables

  • Triage summary and immediate recommendations
  • Annotated transaction timeline
  • Fund-flow trace with address annotations
  • Root-cause analysis
  • Post-incident report and hardening plan

Relevant research

Read the work behind the service.

Incident analyses, case studies and the research behind the attack classes they cover.
Research hub

Publications

Case studies

All case studies

Research assessments

Security assessments library
Compare all services

FAQ

Questions teams ask before an engagement

It depends on availability at the time of request. We do not offer guaranteed response times through this website. If your team needs agreed response commitments, raise it during scoping so the terms can be discussed in writing before an incident happens.

We cannot promise recovery. Tracing helps identify where funds went and which services they passed through, which can support freezes, negotiations or law-enforcement action by the relevant parties.

No. Incident work is confidential. Any public communication, including a post-mortem, is your decision and is published only with your approval.

The affected chain and contracts, what was observed and when, transaction hashes, and how to reach your team securely. Never send private keys, seed phrases or credentials.

Yes, and it is the most effective option. An incident plan, monitoring of privileged operations and a rehearsed pause procedure shorten the first hours considerably.

Incident inquiry

Tell us what is happening.

Inquiries are reviewed as they arrive. We will tell you whether we can take the engagement, and agree a secure channel before discussing details.

Useful to include

  • Affected chain and contract addresses
  • Transaction hashes you have identified
  • What has been done so far
  • Who is on your response team

Never send private keys, seed phrases or credentials.

Fields marked with * are required.

Prepare before you need it.

An incident plan, monitoring of privileged operations and a rehearsed pause procedure make the first hours of an incident shorter and calmer.

Discuss incident readinessOn-chain monitoring