Binance Hacked: Crypto Exchange Penetration Testing Checklist

Crypto exchange penetration testing should follow the path from a user request to a change in balances or spending authority. That path crosses web applications, APIs, approval workflows, signing services, wallet state, and sometimes smart contracts. A proposal that tests only public endpoints or only Solidity code leaves important questions unanswered.

The October 2026 Binance incident has made those boundaries urgent, but the scope below is a proposed testing model for an organization’s own exchange, custody service, or blockchain application. It is not an assessment of Binance and does not assume that any particular implementation is vulnerable. Start with synthetic accounts, isolated signing fixtures, and an explicit prohibition on production fund movement.

Blockchain penetration testing and smart contract audits cover different systems

A smart contract audit examines contract code, design assumptions, and relevant execution behavior. A web or API pentest investigates application access and workflows. Ethereum’s smart contract security guidance describes testing, independent review, and other assurance techniques, while cautioning that audits do not catch every bug. Neither a contract audit nor a web test should silently inherit the other’s scope.

Ask who owns each row. If the vendor cannot test the signing service or contracts, retain those as explicit exclusions and commission the missing expertise. A broad “blockchain security” label is not evidence that every layer was examined.

Build an API test around roles, tenants and state

En Top 10 de seguridad de las API de OWASP distinguishes object authorization, function authorization, authentication, and sensitive business-flow risks. Translate those categories into exchange-specific fixtures rather than sending the same request with random identifiers and assuming a response code tells the full story.

Create two test tenants with similar synthetic objects, a read-only identity, an ordinary operator, and a separate approver. Agree on the allowed state for each identity. For an attempted unauthorized action, inspect the response, stored object, queued job, and audit event. A request that returns an error after already creating a withdrawal job is not a successful denial.

Separate exchange API credentials from blockchain signing authority. Binance’s public Spot REST documentation, for example, distinguishes endpoint permissions and signed requests, with timestamp and validity-window checks. That is useful API design context, not a disclosure of the incident’s cause. An exchange API request signature and an EVM account authorization are different objects with different verification paths.

A useful negative-test matrix includes cross-tenant object access, read-only credentials attempting a write, an operator attempting approval, stale requests, mismatched approvals, and a retry after the original session is revoked. Include the expected postcondition in every case. “HTTP 403” alone does not demonstrate that downstream work was prevented.

Test withdrawal idempotency with local fixtures

Withdrawal retries need a precise contract. A proposed design is to scope each idempotency key to the tenant and operation, then require an identical payload for a replay. The following offline example illustrates that acceptance rule. It is a toy model, not an exchange implementation or a production control: a deployed service also needs atomic storage, concurrency handling, retention policy, authentication, and transaction-safe accounting.

from hashlib import sha256
from json import dumps

seen = {}

def reserve(tenant, operation, key, payload):
    scope = (tenant, operation, key)
    digest = sha256(dumps(payload, sort_keys=True).encode()).hexdigest()
    if scope in seen:
        old_digest, request_id = seen[scope]
        if digest != old_digest:
            raise ValueError("key reused with a different payload")
        return request_id
    request_id = f"synthetic-{len(seen) + 1}"
    seen[scope] = (digest, request_id)
    return request_id

p = {"asset": "TEST", "amount": "1", "destination": "fixture-A"}
a = reserve("tenant-A", "withdraw", "retry-1", p)
assert reserve("tenant-A", "withdraw", "retry-1", p) == a
assert reserve("tenant-B", "withdraw", "retry-1", p) != a
try:
    reserve("tenant-A", "withdraw", "retry-1", dict(p, amount="2"))
except ValueError:
    pass
else:
    raise AssertionError("changed payload was accepted")

The integration test should go further than this in-memory fixture: race two approved test requests, interrupt a worker between state changes, and replay after recovery. Observe whether one request can produce two business effects. Use only an isolated environment and a synthetic ledger until the owner has approved a bounded production-safe verification.

Treat the signer as a separate trust boundary

A signing service should receive more than a vague “approved” flag. Our proposed test contract binds approval to the operation type, relevant chain and account, destination or delegate, transaction contents, policy version, and authorization context. A mutation between approval and signing should fail closed. Specialists should decide the exact canonical representation and cryptographic binding for the implementation being assessed.

For EIP-7702-capable systems, a delegation request deserves its own policy classification. The EIP-7702 specification describes authorizations that change account execution behavior. The relevant acceptance test is whether an operation outside the permitted class reaches the signing boundary, even if another internal service presents it as routine business.

This is also where product claims need discipline. An API test cannot prove that an HSM key is non-extractable, that an MPC deployment has an appropriate threat model, or that a delegate contract safely implements permissions. Ask for the relevant specialist scope, access, assumptions, and evidence. Report an inaccessible signing layer as untested rather than “secure.”

Make the report follow the actual evidence chain

Each finding should connect a precondition to an observed unauthorized outcome. Preserve a redacted request or signed-fixture reference, identity and role, environment and build, expected rule, actual state transition, audit-event correlation, impact limit, and reproduction steps. When the result depends on a permissive test configuration, state that dependency.

For wallet observations, keep the chain and block reference next to the result. For asynchronous application behavior, connect the incoming request to the worker decision and ledger event. If that correlation is unavailable, make the observability gap explicit; do not bridge it with an invented attack chain.

Retesting should repeat the original case and a nearby legitimate workflow. A fix that blocks the negative case while making all withdrawals fail is not a complete operational resolution. Record whether the same identity, state, and concurrency conditions were reproduced, and distinguish code review from executed verification.

What to put in a crypto exchange pentest brief

A useful request for proposal describes the assets and the decisions being tested. Include approved domains and API versions, tenant fixtures, user roles, worker and signer access, contract commits if relevant, environment, test-asset limits, allowed techniques, rate ceilings, stop conditions, and escalation contacts. State whether social engineering, cloud configuration, third-party custody integrations, and production verification are excluded.

Require deliverables by coverage area: a test matrix with evidence links, reproducible findings, limitations, remediation owners, and a retest result. Price comparisons are meaningful only when those commitments match. A cheaper application-only assessment may be a sensible first step, but it should not be purchased as assurance for an untested custody stack.

Penligent can support the authorized application and API investigation portion by connecting scoped work, security tools, finding verification, and editable reports. Keep smart contract auditing, signing-policy assurance, and HSM or MPC assessment as explicit workstreams with qualified reviewers. That boundary makes the report more useful to a buyer than a promise to “test everything.”

Common scope questions

What is crypto exchange penetration testing?

• An authorized assessment of the exchange surfaces named in the scope, with controlled validation of access and business impact. The contract should say whether APIs, wallets, signing workflows, and infrastructure are included.

Is blockchain penetration testing just a smart contract audit?

• No. A blockchain application can also have account, API, cloud, front-end, and operational weaknesses. Code auditing and application testing should be scoped and reported separately.

Can the test use real deposits and withdrawals?

• Begin with synthetic assets and isolated environments. Any production-safe verification needs an explicit value limit, approved procedure, and stop condition from the owner.

Can an AI pentest replace specialist custody review?

• No. Tools can help investigate application behavior and collect evidence; custody assurance needs the relevant architecture, key-management, and signing expertise.

What should a buyer accept as a completed engagement?

• A report tied to agreed assets and versions, with tested cases, reproducible outcomes, exclusions, remediation actions, and a defined retest. A scanner summary or a list of tool names is insufficient evidence of the promised workflow coverage.