Skip to content
Quantix Security Labs

Threat Intelligence

Threat intelligence connects what attackers are doing across the ecosystem to the specific exposure of your protocol. Quantix analysts study exploit techniques, malicious contract patterns, phishing infrastructure and fund-laundering paths, then map them to your architecture as prioritised briefings, detection rules and hardening actions.

Attacker techniques, tracked and translated into controls.

Request a briefingOpen Threat Analysis
Dark illustration of a network of protocols and wallets beneath three translucent intelligence layers — techniques, indicators and actors — with markers projecting onto the network.

Service overview

Intelligence is only useful when it changes a control.

We study how attacks against decentralised systems are prepared, executed and monetised, then map that knowledge to your architecture.

Most exploits reuse a technique that has worked before, against a protocol that shares its preconditions. Threat intelligence closes that gap: it tracks techniques as they appear across the ecosystem, works out which of your contracts and flows share the preconditions, and turns that into indicators, detection rules and hardening actions.

The work is technical rather than speculative. Every technique is tied to a vulnerability class, a stage of the attack and an observable signal. Every indicator carries a confidence level and an expiry. Every briefing ends with actions and the risk each one removes.

We attribute techniques and infrastructure, not identities. Attribution to individuals is a matter for the relevant authorities.

Tracks
Exploit techniques, drainer infrastructure, pre-attack indicators
Delivers
Briefings, indicator sets, detection rules, exposure maps
Cadence
Agreed per engagement, plus ad-hoc briefings when a technique affects you

Applies to

  • DeFi protocols and their integrations
  • Wallets and front-end infrastructure
  • Bridges and cross-chain messaging
  • Exchanges and custody providers
  • Security operations teams
Technique trackingIndicator developmentExposure mappingAnalyst briefings

Threat landscape: where attacks start and what each stage looks like

Six attack surfaces across three stages. Each cell is an observable signal, which is what makes the stage detectable.

  • Contract logic

    Reentrancy, rounding, validation gaps

    PreparationAttack contract deployed and funded shortly before use; test calls against a fork-like target
    ExecutionSingle transaction with unusual call ordering or nested callbacks into the victim
    MonetisationProceeds split across fresh addresses within the same or next block

  • Economic and oracle

    Price manipulation, flash loans

    PreparationLiquidity mapping of thin pools that feed a price; flash-loan sources identified
    ExecutionBorrow, move price, extract, repay within one transaction
    MonetisationSwaps into stable assets, then bridge deposits

  • Keys and access

    Compromised admin, deployer or signer keys

    PreparationPhishing or malware against signers; new devices or sessions on signing infrastructure
    ExecutionRole transfer, unexpected upgrade or treasury transfer by a privileged key
    MonetisationRapid movement to many addresses, mixers or cross-chain routes

  • Cross-chain

    Message forgery, replay, validator compromise

    PreparationProbing of verifier contracts; messages crafted for unused destinations
    ExecutionRelease on destination without a matching, valid deposit on the source
    MonetisationFunds dispersed on the destination chain where tracing coverage is weaker

  • Users and frontends

    Drainers, approval phishing, address poisoning

    PreparationLook-alike domains registered; drainer contracts deployed with permit and transferFrom sweepers
    ExecutionWaves of approvals or permits to one new spender, followed by sweeps
    MonetisationConsolidation and fee split between drainer operators and affiliates

  • Governance

    Vote borrowing, malicious proposals

    PreparationAccumulation or borrowing of voting power; proposal drafted with obscured calldata
    ExecutionProposal queued and executed at the earliest possible block
    MonetisationTreasury assets moved and sold through on-chain venues

Threats addressed

The activity we track.

Grouped by what the attacker is trying to do. The technique taxonomy below breaks each group into techniques mapped to vulnerability classes.
  • Contract exploitation

    Logic and economic exploits

    Attacks on accounting, oracle and liquidity assumptions, often funded with flash loans and executed in one transaction.

  • Drainer infrastructure

    Approval and permit phishing

    Kits that collect signatures through look-alike sites and compromised integrations, then sweep balances.

  • Key compromise

    Attacks on signers and operators

    Phishing, malware and infrastructure intrusion aimed at the people and machines that hold privileged keys.

  • Cross-chain

    Bridge and messaging attacks

    Forged, replayed or misrouted messages that release funds without a valid deposit.

  • Governance

    Governance capture

    Borrowed voting power and proposals whose calldata does more than their description says.

  • Supply chain

    Frontend and dependency compromise

    Malicious packages, CDN or DNS changes that turn a trusted interface into an attack surface.

  • Address poisoning

    Look-alike addresses

    Zero-value or dust transfers from addresses that mimic a counterparty, hoping to be copied from history.

  • Pre-attack signals

    Preparation on-chain

    Attack contracts deployed and funded, test transactions and liquidity mapping before the main event.

  • Monetisation

    Laundering paths

    How proceeds are dispersed, swapped and bridged, and which points in that path allow intervention.

Technique taxonomy.

13 techniques tracked in briefings, each mapped to the vulnerability class used in Quantix reports, the stage it belongs to, what it looks like on-chain and the control that answers it.

Preparation 3 · Execution 9 · Monetisation 1

Attack techniques mapped to vulnerability classes, stages, indicators and controls
IDTechniqueClassStageOn-chain indicatorPrimary control
QX-T01Spot-price manipulation of a thin poolOracle manipulationExecutionLarge swap on a pool that feeds a price, followed by a borrow or mint in the same transactionMulti-source or time-weighted prices, deviation bounds, liquidity floors
QX-T02Flash-loan funded invariant breakFlash-loan attackExecutionFlash-loan callback that calls state-changing protocol functions and repays in the same transactionInvariant checks at the end of entry points, per-block limits
QX-T03Share inflation of an empty vaultFirst-depositor attackExecutionDirect token donation to a vault with zero or one share before the first real depositVirtual shares and decimals offset, seeded initial deposit
QX-T04Stale price read during a callbackRead-only reentrancyExecutionView function of an external pool read while that pool is mid-operationCheck the external reentrancy lock before reading, or avoid manipulable views
QX-T05Permit and Permit2 signature phishingSignature phishingExecutionOff-chain signatures redeemed by one new spender, then transferFrom sweeps across many holdersReadable typed-data prompts, spender allowlists, revocation tooling
QX-T06Cross-domain signature replaySignature replayExecutionThe same signature or message accepted by a second chain or contractEIP-712 domain with chainId and verifyingContract, per-signer nonces
QX-T07Upgrade through a compromised administratorUnsafe proxy upgradeExecutionUpgraded event to an implementation that matches no approved releaseTimelocked, multisig-controlled upgrades and implementation monitoring
QX-T08Forged or replayed bridge messageBridge message validationExecutionRelease on the destination without a matching, valid deposit on the sourceProof verification, per-destination nonces, release rate limits
QX-T09Borrowed voting powerGovernance manipulationPreparationVoting power acquired shortly before a proposal that moves treasury funds or rolesSnapshot at proposal creation, timelock, guardian veto
QX-T10Frontend dependency injectionSupply chainPreparationChanged script hashes, or the interface requesting approvals for a spender it never used beforeSubresource integrity, content security policy, build provenance
QX-T11Operational signer compromiseKey managementPreparationSigner activity outside its schedule, or from new infrastructureHardware or MPC signing, scoped roles, rate-limited privileges
QX-T12Account substitution in a Solana programAccount validationExecutionInstruction that passes an attacker-owned account where a program-owned one was expectedOwner, signer and seed checks; Anchor account constraints
QX-T13Fast dispersal after an exploitBusiness logicMonetisationProceeds split into many fresh addresses, swapped and bridged within minutesPre-agreed contacts at bridges and venues, rapid tracing

Technical capabilities

From observation to a control that holds.

Six capabilities, each producing something your engineers or security team can use directly.

  • Technique tracking

    New techniques analysed from incidents and research, and added to the taxonomy with their preconditions.

  • Indicator development

    Typed indicators with confidence and expiry, so they can be trusted and retired rather than piling up.

  • Exposure mapping

    Which of your contracts, integrations and flows share the preconditions of a technique, ranked.

  • Detection engineering

    Monitoring rules written for each relevant technique and replayed against history before use.

  • Analyst briefings

    Written briefings and calls with the analyst who did the work, for your engineers and leadership.

  • Post-incident analysis

    When something happens in the ecosystem, what it means for you, usually before a full post-mortem exists.

Assessment methodology

An indicator has a life cycle, and an end.

Observations become indicators, indicators become rules, rules are reviewed. Indicators that never expire become noise, so retirement is part of the method.
The seven-stage Quantix workflow
Indicator lifecycleSix stages from left to right: observe, analyse, codify as an indicator, detect with a deployed rule, act on the alert, and review. From review, an indicator is either refined and returned to analysis, or retired when it expires or stops being relevant.01Observeincident, exploit ornew contract seen02Analysetechnique, preconditions,infrastructure03Codifyindicator with type,confidence, expiry04Detectrule deployed againstclient exposure05Actalert, block, revokeor harden06Reviewhit rate, falsepositives, relevancerefineretire at expiryEvery indicator carries a confidence level and an expiry date set when it is codified.
  1. 01

    Collection

    Incident reports, on-chain activity, new contract deployments, research publications and client telemetry where shared.

  2. 02

    Technique analysis

    What the attacker did, step by step, and which preconditions made it possible.

  3. 03

    Exposure mapping

    Those preconditions compared with your architecture, integrations and user flows.

  4. 04

    Indicators and rules

    Indicators codified with type, confidence and expiry; detection rules written and replayed against history.

  5. 05

    Briefing

    Findings, indicators, rules and actions delivered in a fixed structure, with a sharing marking.

  6. 06

    Review and retirement

    Hit rates and false positives reviewed; indicators refined or retired at expiry.

The structure of a briefing.

Every briefing follows the same structure, so it can be read in two minutes by a decision maker and acted on in an afternoon by an engineer. It is shown here with the Larkspur permit-phishing incident from Quantix Threat Analysis.

Briefings carry a Traffic Light Protocol marking that tells recipients how far they may share it.

Analysed incidents in Threat Analysis
QX-TB-2026-05TLP:AMBERLarkspur permit-phishing incident18 May 2026

Permit signatures collected through a compromised wallet integration

  • QX-T05 Permit and Permit2 signature phishing
  • QX-T10 Frontend dependency injection
  • QX-T13 Fast dispersal after an exploit
  1. 01SummaryWhat happened, who is exposed and the one action that matters most, in three sentences for decision makers.
  2. 02TechniqueThe attack described step by step and mapped to the taxonomy, with the preconditions it relies on.
  3. 03ExposureWhich of the client’s contracts, integrations and user flows share those preconditions, ranked.
  4. 04IndicatorsTyped indicators with confidence and expiry: spender contracts, typed-data patterns, domains, funding sources.
  5. 05Detection logicRules that would have fired on this activity, written for the client’s monitoring stack.
  6. 06Recommended actionsImmediate, short-term and structural actions, each with an owner role and the risk it removes.
  7. 07Confidence and sourcesHow sure the analysis is, what it is based on, and what would change the assessment.
Indicator set
Indicator typeConfidenceExpiry
Spender contractHigh90 days
EIP-712 typed-data patternHighUntil revoked
Look-alike domain patternMedium30 days
Funding source clusterMedium60 days

Tools & techniques

Open standards for sharing, public data for analysis.

Indicators are delivered in standard formats so they work with the tools your team already runs.
Tools and techniques used for Threat Intelligence
Tool or techniqueCategoryWhat it is used for
Transaction tracing and decodingAnalysisCall traces, state diffs and decoded calldata for every transaction in an attack.
Bytecode decompilation and similarityAnalysisCompares unverified attack and drainer contracts with known families by structure and selectors.
Function signature databasesAnalysisPublic selector and event signature databases to decode unverified contracts.
New-contract and funding watchCollectionFlags freshly deployed contracts that match known attack patterns, and how they were funded.
Certificate Transparency logsCollectionFinds look-alike domains as certificates are issued for them.
STIX 2.1 and TAXII 2.1SharingOASIS standards for structured indicators and their delivery to your security tools.
Traffic Light Protocol 2.0SharingFIRST’s marking scheme for how far a briefing may be shared.
Rules as codeDetectionDetection rules versioned with tests against recorded incidents, ready for your monitoring stack.

Ecosystem coverage

Technical depth per execution environment.

Techniques differ by execution model. Briefings are written for the ecosystems your protocol and users actually touch.

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

Intelligence in forms your tools and people can use.

Delivered on an agreed cadence, with ad-hoc briefings when a new technique affects your exposure.

  • Threat landscape briefing

    The techniques and actors most relevant to your stack, with exposure ranked.

  • Indicator sets

    Typed, confidence-rated indicators with expiry, in STIX 2.1 or a format you specify.

  • Detection rules

    Rules for your monitoring stack, each tied to a technique and replayed against history.

  • Exposure assessment

    Which contracts, integrations and flows share a technique’s preconditions, and what to change.

  • Periodic reports

    What changed in the landscape since the last report and what it means for you.

  • Analyst access

    Questions answered by the analysts who wrote the briefing.

Key assessment areas

  • Exploit technique tracking
  • Malicious contract and approval patterns
  • Phishing and drainer infrastructure
  • Pre-attack on-chain indicators
  • Laundering paths after an incident
  • Exposure mapping to your architecture

Typical deliverables

  • Threat landscape briefing for your stack
  • Indicator sets and detection rules
  • Exposure assessment with prioritised actions
  • Periodic intelligence reports
Quantix IntelligenceThreat analysisIncidents analysed with the taxonomy above: technique, timeline, indicators and the controls that would have stopped it.

Relevant research

Read the work behind the service.

Technique research, incident case studies and the assessments where those techniques were found before they were used.
Research hub

Publications

Case studies

All case studies

Research assessments

Security assessments library
Compare all services

FAQ

Questions teams ask before an engagement

Techniques, classes and controls are real and documented publicly. The incidents used to illustrate them on this site, including the briefing above, come from Quantix Protocol Research, whose protocols are modelled rather than real, so no real project is named as a victim.

As written briefings, indicator sets in STIX 2.1 or a format you specify, and detection rules for your monitoring stack. Cadence is agreed per engagement.

The Traffic Light Protocol, maintained by FIRST, tells recipients how far a document may be shared: TLP:CLEAR without restriction, TLP:GREEN within the community, TLP:AMBER within the recipient organisation and its clients as needed, TLP:RED to named recipients only.

No. We attribute techniques, infrastructure and fund flows. Identifying individuals is a matter for the relevant authorities.

Monitoring watches your contracts. Threat intelligence watches the ecosystem for techniques that could be used against them, and feeds new rules into monitoring when it finds one.

Know which attacks apply to you.

Tell us what you run and which integrations your users rely on. We will reply with the techniques most relevant to your stack and how a briefing would be scoped.

Request a briefingOn-chain monitoring