Notifications
Clear all
Topic starter
11/08/2026 3:22 pm
TL;DR: MITRE’s AADAPT gives teams a common way to model adversary techniques against digital-asset systems, and Bishop Fox argues red teaming is the practical way to test whether those techniques can manipulate business logic, signing paths, or value flows before losses become irreversible. The security problem is no longer just system compromise; it is whether attackers can corrupt economic logic faster than detection and containment can react.
NHIMG editorial — based on content published by Bishop Fox: a guide to operationalising AADAPT through red teaming for digital asset security
Questions worth separating out
Q: What breaks when signing identities and service accounts are not governed in digital asset systems?
A: Value-moving workflows become vulnerable to abuse because the identities that authorise transactions can be reused, over-permissioned, or compromised.
Q: Why do digital asset systems need red teaming instead of framework-only assessments?
A: Frameworks describe adversary behaviour, but they do not prove whether a specific environment can stop it.
Q: How do security teams know if AADAPT-based controls are actually working?
A: Look for three signals: the attack path was exercised, the relevant telemetry was captured, and containment happened before value loss became irreversible.
Practitioner guidance
- Inventory every value-bearing identity path Map custodial signing services, CI/CD tokens, operator accounts, oracle dependencies, and bridge integrations before planning red team scenarios.
- Test high-impact AADAPT techniques in safe environments Use forked mainnets, isolated testnets, or replicated sandboxes to simulate flash-loan manipulation, oracle poisoning, signing abuse, and cross-chain evasion without risking live funds.
- Correlate identity and chain telemetry Tie transaction traces, signer identity, KMS or HSM events, and oracle metadata to the same incident timeline so analysts can reconstruct the attack sequence end to end.
What's in the full article
Bishop Fox's full article covers the operational detail this post intentionally leaves for the source:
- Scenario-by-scenario offensive test design for flash-loan, oracle, signing, and cross-chain abuse
- Telemetry requirements for reconstructing transaction traces, signer identity, KMS or HSM events, and oracle metadata
- Purple-team cadence guidance for moving from detection hypothesis to validated containment
- Safe-environment practices for forked mainnets, rollback planning, and stakeholder sign-off
👉 Read Bishop Fox's guide to red teaming AADAPT-aligned digital asset attacks →
AADAPT red teaming for digital assets: are your controls keeping up?
Explore further
11/08/2026 3:32 pm
AADAPT makes digital asset security a governance problem, not just a blockchain problem. The article is right to frame value-bearing systems as an attack surface that includes signing services, oracle inputs, bridge workflows, and service accounts. That matters because the control point is often identity and authorisation, not the chain itself. Practitioners should treat every value-moving path as a governed trust boundary.
A question worth separating out:
Q: How do security teams know if AADAPT-based controls are actually working?
A: Look for three signals: the attack path was exercised, the relevant telemetry was captured, and containment happened before value loss became irreversible. If any of those is missing, the programme has not validated the control. Success is not a clean alert alone. It is demonstrable interruption of economically harmful behaviour.
👉 Read our full editorial: AADAPT red teaming shows how digital asset attacks turn logic into loss
