Crypto Exchange Penetration Testing & Smart Contract Review in Bangalore

Indian crypto exchanges, custodians, and broker-dealers operate in one of the most-tested compliance environments in the world. PMLA registration with FIU-IND is mandatory. The Prevention of Money Laundering rules require periodic security audits. Banking-channel access is conditioned on demonstrable security controls. UAE expansion under VARA adds another regulatory layer. For the engineering teams running these platforms, security is not a periodic exercise — it is the operational floor on which the rest of the business depends. This page describes our exchange-pentest methodology, the regulatory frameworks it aligns to, and the engagement model for Indian VDA Service Providers.

Why crypto exchange security is different

Three properties make exchange security its own discipline. First, the attack surface combines traditional web/API security with on-chain smart-contract security and custody operational security — three different specialisations that have to converge in a single engagement. Second, every transaction is irreversible. A successful attack is not a data breach to be reported and remediated; it is funds permanently lost. Third, the threat actor model is sophisticated and well-resourced — exchange compromises are routinely attributed to nation-state-aligned groups, organised crime, and well-funded private actors with operational security playbooks that match those of legitimate engineering teams.

The implication is that an exchange engagement cannot be a checklist VAPT. It requires senior auditors with cross-domain experience and a methodology designed for the specific class of asset.

FIU-IND VDA SP framework

The Financial Intelligence Unit – India (FIU-IND), operating under the Department of Revenue, Ministry of Finance, registers Virtual Digital Asset Service Providers under the Prevention of Money Laundering Act, 2002 and the Prevention of Money-laundering (Maintenance of Records) Rules, 2005. The PMLA framework, extended to VDA SPs in 2023, imposes a comprehensive AML / CFT regime including KYC, transaction monitoring, suspicious-transaction reporting, and information-security obligations.

The information-security obligation requires registered VDA SPs to maintain a documented security regime, conduct periodic security audits, and retain audit reports for the FIU’s inspection. CERT-In empanelment is the de-facto requirement for the auditor; our reports satisfy this requirement explicitly. The audit covers: customer-data protection, transaction-data integrity, wallet operational security, key-management lifecycle, third-party integration security, and incident-response capability.

Hot / warm / cold wallet review

Wallet architecture review is the most-impactful single section of any exchange engagement. The conventional architecture splits funds across three tiers:

Hot wallets

Online, automatically-signing wallets used for routine withdrawals. Held on internet-connected infrastructure with API-driven signing. Highest convenience, highest exposure. Best practice: minimal balance (typically less than 5% of total exchange custody), automated rebalancing from warm wallets, withdrawal-limit enforcement, IP-allowlisting for the signing service, HSM-backed keys (CloudHSM, AWS KMS Custom Key Store, or dedicated SafeNet / Thales hardware), and continuous monitoring of all transactions.

Warm wallets

Online but require human approval for signing (typically multi-sig). Used for larger withdrawals or batch rebalancing. Best practice: M-of-N multi-sig with geographically-distributed signers, time-locked transactions for withdrawals above a threshold, dual-control on signing, signed-transaction air-gap from the exchange’s primary network where feasible.

Cold wallets

Offline, air-gapped storage. Used for long-term custody and backup. Best practice: hardware-wallet-based key generation in a documented ceremony, M-of-N multi-sig with multiple geographically-distributed officers each holding shares, key generation on hardware that has never connected to the internet, recovery procedures tested annually, and an inheritance / continuity plan for officer turnover.

Our engagement examines each tier’s implementation against the best-practice baseline, identifies gaps (e.g. hot wallets holding more than 5% of total custody, warm wallets without time-locks, cold wallet key-generation ceremony not documented), and recommends specific remediations.

Smart contract security review

Smart-contract review is its own deliverable, often run alongside the exchange engagement for platforms operating their own DEX, lending protocol, staking module, or token. Methodology covers four phases.

Phase 1 — Automated analysis

Slither, Mythril, MythX for symbolic execution; Echidna and Foundry for property-based fuzzing; Manticore where appropriate. Output: a baseline issues list including known-vulnerability patterns.

Phase 2 — Manual review

Senior auditor reads the contract suite line-by-line, traces each external entry point, examines authorisation, reviews state transitions, validates invariants, examines token-economic assumptions, identifies oracle dependencies, and looks for known patterns of MEV exposure, reentrancy (cross-function and read-only), governance attack surfaces, and access-control gaps.

Phase 3 — Property-based testing

We write Foundry-based property tests against your invariants (e.g. "total supply equals sum of balances," "user balances never exceed deposits + earned rewards") and run extended fuzzing campaigns. Failed properties are escalated to manual triage.

Phase 4 — Reporting

Audit report with severity-graded findings, reproduction (Foundry test cases where applicable), remediation guidance, and (optionally) a published version for token-launch credibility purposes. Our published audits are visible on Github and on the partner’s site post-engagement.

KYC / AML pipeline testing

The KYC / AML pipeline is the regulatory backbone of an exchange. Our engagement examines:

• KYC onboarding — identity-document verification, liveness detection, deep-fake detection, document-tampering checks, OCR accuracy
• PEP / sanctions screening — list-update cadence (OFAC, EU, UN, India MEA, MHA, FIU-IND), screening accuracy, false-positive review workflow
• Transaction monitoring — rule coverage, threshold tuning, alert investigation workflow, false-positive rate
• STR / SAR filing — filing workflow, FIU-IND submission, regulator-response handling
• Source-of-funds verification — for high-value deposits
• KYT (Know Your Transaction) — Chainalysis / TRM / Elliptic integration, address-risk-scoring thresholds, withdrawal-screening workflow

Trading API and market-making security

The trading API is where most exchange-attack scenarios concentrate. Specific test areas:

• Authentication — API-key entropy, HMAC implementation, replay protection, IP allowlisting
• Authorisation — per-key permission scoping (read-only, trading, withdrawal), per-key withdrawal-address allowlists
• Rate limiting — endpoint-specific limits, prevention of order-book manipulation via spam orders
• Order-book integrity — front-running prevention, batch auction implementation, tick-level price manipulation
• Withdrawal flow — multi-step approval, blockchain-confirmation waiting, address-allowlist enforcement
• Market-maker integration — co-location latency abuse, FIX-protocol implementation security, liquidity-fragmentation manipulation
• WebSocket security — per-connection authorisation, channel-level access control, message-authentication on user-private channels

On-chain forensics and address risk

The chain-analytics integration is a separate workstream. We review your KYT vendor selection (Chainalysis Reactor, TRM Labs, Elliptic), the integration depth (every withdrawal screened? every deposit screened? batch vs real-time?), the threshold configuration (block low-risk; review medium-risk; freeze high-risk; auto-flag sanctioned), and the analyst workflow for handling flagged transactions.

For Indian-context risks specifically, we maintain an internal address-risk database that augments commercial sources — UPI-fraud-linked addresses, known mule-account clusters, FIU-IND-flagged addresses where public, and addresses linked to specific Indian-origin scams (loan-app fraud cluster addresses, fake-investment-platform clusters, etc.). This data layer is delivered as part of our engagement and is included in your KYT integration if you choose to consume it.

Engagement methodology

The engagement runs as five workstreams in parallel: infrastructure / cloud (using our cloud methodology), web / API (our web methodology), mobile applications if exchange offers a consumer mobile app (our mobile methodology), wallet architecture and operational security (this page), and smart contracts (this page).

Pricing in INR

Common findings in Indian VDA platforms

1. Hot wallets holding more than 5% of total exchange custody
2. Multi-sig recovery procedures not tested in last 12 months
3. API keys without per-key withdrawal-address allowlisting
4. Withdrawal flow without time-locks for above-threshold amounts
5. KYT integration only on deposits, not withdrawals
6. Sanctions list updates lagging by more than 7 days
7. Smart contracts using outdated Solidity (0.6 / 0.7 still in production)
8. Reentrancy in cross-function calls (read-only reentrancy especially)
9. Oracle reliance on a single source without fallback
10. Admin keys for upgradeable contracts on hot multisig (should be cold)
11. Insufficient SAR filing — reactive rather than proactive
12. Customer KYC documents stored in S3 without encryption
13. Trading API HMAC implementation accepting expired timestamps
14. WebSocket channel without per-connection user authentication
15. Order-book manipulation via spam-order rate-limit bypass
16. Custody backup not geographically distributed
17. HSM access keys on the same network as the application servers
18. FIU-IND STR submission process not tested
19. Banking partner integration without dual-control approval
20. Internal admin panel without IP-allowlist or MFA

Indian-context attack patterns observed in 2025–2026

The threat-actor population targeting Indian-domiciled and Indian-origin VDA platforms has matured significantly through 2025 and 2026. The attack patterns below are drawn from incidents we have responded to and from intelligence shared across the CERT-In information-sharing channels.

Pattern 1 — Phishing the operations team for support-tool access

Adversaries target customer-support staff with spear-phishing pretexts (supplier impersonation, internal-IT impersonation, business-application-vendor impersonation) to harvest credentials for the customer-support admin tool. Once access is obtained, the adversary uses legitimate support-tool features to override security holds, freeze withdrawal-cooldowns, and approve withdrawals to attacker-controlled addresses. Defence: hard-coded geographic IP restrictions for support-tool access, hardware-key-only MFA, separate admin-account lifecycle from primary email account, just-in-time elevation for high-impact actions.

Pattern 2 — Supply-chain attack via npm / pypi / git repository

Adversaries inject malicious code into a package the exchange depends on (typically a less-prominent package the maintainer can be socially engineered against). The malicious code activates conditionally — only on production environments, only with specific environment variables, only at specific times — to evade detection during normal CI. Defence: pinned dependencies with hash verification, software-bill-of-materials maintenance, run-time monitoring for unexpected outbound connections from production builds, limited package-update cadence with verification.

Pattern 3 — Insider access leveraged to manipulate internal balances

Disgruntled or compromised insider with access to internal-balance ledger uses legitimate features to credit specific accounts, then withdraws. Frequency: low but high-impact. Defence: separation-of-duties enforced via role-based access (no single individual can both modify balances and approve withdrawals), automated alerts on anomalous balance-modification patterns, immutable audit log shipped to off-platform storage.

Pattern 4 — Smart-contract reentrancy in lending / staking modules

Exchange operates an ancillary lending or staking smart-contract module; the contract has cross-function reentrancy vulnerability; attacker drains the contract via a flash-loan-funded re-entrant call. Defence: reentrancy-guard usage on all state-modifying external calls, formal property-based testing with Foundry, MEV-protection design where applicable.

Pattern 5 — Trading API key theft via developer machine compromise

Power user / market maker has API keys stored in plaintext on a personal machine; machine is compromised by infostealer malware (typically distributed via malicious browser extension or pirated software); attacker uses the harvested keys to drain the user’s account. Defence: API-key-specific withdrawal-address allowlists (so even if the key is stolen, the attacker can only withdraw to pre-approved addresses), short-TTL keys with automatic rotation, mandatory IP allowlisting for high-volume keys.

Indian VDA regulatory overview — what intersects with cybersecurity

Indian regulation of virtual digital assets in 2026 is a layered structure. The 2022 Finance Act introduced taxation of VDAs (30% flat tax on income from transfer of VDAs, plus a 1% TDS at source on transactions above specified thresholds) — operationally significant but not a cybersecurity framework per se. The 2023 amendment to PMLA brought VDA SPs into the AML/CFT regime under FIU-IND. The Information Technology Act, 2000 and the CERT-In Direction 20(3)/2022 apply to all Indian electronic-service providers and impose incident-reporting obligations within six hours.

Sectoral regulators interact unevenly. RBI does not directly regulate VDA exchanges but has issued banking-channel guidance affecting fiat-on-ramp / fiat-off-ramp services. SEBI regulates derivatives and securities; many SEBI-regulated entities have begun offering VDA-adjacent products and inherit SEBI’s cybersecurity framework — see our SEBI CSCRF page. State-level law-enforcement engagement is increasingly active; Bangalore’s Cyber Crime Cell handles a substantial portion of India’s VDA-related criminal investigations and we maintain working relationships with the cell’s technical staff.

The DPDP Act applies to personal data of customers; KYC documentation, transaction history, and customer interactions are all in scope. See our DPDP service page for the structure that applies. Most Indian exchanges hold a combination of FIU-IND registration + DPDP Data Fiduciary obligations + ISO 27001 certification (we are typically engaged for the ISO certification work in addition to the exchange-specific cybersecurity engagement).

Bangalore as the centre of India’s VDA engineering

Most India-headquartered or India-operating VDA exchanges, custodians, and infrastructure providers have substantial Bangalore engineering presence. This is partly a function of talent — Bengaluru’s blockchain engineering pool is the largest in India by a meaningful margin — and partly a function of the venture-capital ecosystem, which historically has been Bangalore-centric. Most of our exchange engagements are delivered with one or two on-site weeks at the client’s Bangalore engineering centre, with remote work for the balance.

The local ecosystem also produces specific operational realities: clustered talent movement (engineers move between exchanges every 2–3 years, taking institutional knowledge with them; we see the same operational patterns repeat across exchanges as engineers carry approaches forward), shared vendor base (most exchanges use a similar set of cloud providers, KYT vendors, and HSM vendors, which means our institutional knowledge of how those vendors’ APIs behave under stress is high), and concentrated regulatory exposure (Bangalore-based exchanges share the same banking partners and the same regulatory engagement experiences, so our advice cross-pollinates with appropriate confidentiality).

Key management — the central operational discipline

Key management is the most-consequential single discipline in any exchange’s operational security. Every other control sits on top of the assumption that the keys are correctly generated, securely stored, properly rotated, and recoverable under disaster scenarios. Most major exchange compromises in the public record have key-management gaps as the proximate cause.

Our key-management review covers nine specific areas. Generation: was the key generated with sufficient entropy on hardware that has never been internet-connected? Hardware-wallet-based generation, dedicated HSM-based generation, or air-gapped offline computer with verified entropy source — these are acceptable; software-only generation on internet-connected hardware is not. Storage: are private keys stored in HSM, hardware wallet, or shamir-shared across geographically-distributed signers? Stored in plaintext on any system, including encrypted-at-rest databases, is a finding. Multi-signature setup: M-of-N configuration appropriate to value held, geographic distribution of signers, separation between signing officers (no two signers in the same physical location for highest-value wallets). Signing-ceremony procedures: documented, witnessed, video-recorded for cold-wallet operations, with chain-of-custody for hardware between ceremonies. Recovery procedures: tested in the last 12 months, recovery-officer roster current, recovery-key shares distributed and accessible. Rotation: documented rotation cadence, especially for officer turnover. Inheritance and continuity: documented officer-departure procedure, post-departure key-share invalidation, and continuity plan for catastrophic loss of multiple officers. Audit-trail: every signing event logged immutably; logs reviewed periodically. Insurance alignment: documentation matches the requirements of the exchange’s custody insurance policy.

The output is a key-management posture report independent of the broader exchange engagement, suitable for sharing with insurers and institutional counterparties as part of the exchange’s due-diligence file.

Evaluating a crypto-exchange security vendor — what to ask

The Indian VDA security market has grown substantially since 2023 and the vendor landscape now ranges from competent specialists to firms repackaging generic VAPT work as crypto-exchange testing. The questions below are useful for separating substance from positioning during your selection process.

Specific exchange experience

Ask: how many crypto exchanges has the firm engaged with as the primary security partner in the last 24 months? How many smart-contract suites has the firm reviewed in the same period? How many key-management ceremonies has the firm observed or designed? The answers separate firms that have done the work from firms that have read about it. We have engaged with most major Indian exchanges, multiple regional UAE-based platforms, and several India-domiciled custody providers; representative engagements available under NDA.

Specific tooling and methodology

Ask: which Solidity static-analysis tools does the firm use? Which fuzzing frameworks? Which on-chain forensics platforms (Chainalysis, TRM, Elliptic) do they integrate with? Vague answers ("we use industry-standard tools") indicate that the responder does not personally use the tools. We use Slither + Mythril for symbolic analysis, Echidna and Foundry for fuzzing, IDA Pro and Hopper for binary analysis, and integrate with all three major on-chain forensics platforms.

Regulatory engagement experience

Ask: has the firm filed reports with FIU-IND, RBI, or VARA? How many times in the last 12 months? Who at the firm has the named relationships with the regulator’s technical-supervision teams? Most procurement teams skip this question; when it gets asked, it surfaces meaningful differentiation.

Incident-response capability

Ask: if our exchange has an incident at 2 AM IST, what is the median time to a senior responder on a call? Generic vendors typically deflect; firms with a real IR retainer offering quote a specific number. Our median MTTR is 9 minutes; see our IR retainer page.

Engagement structure and partner accountability

Ask: who at the firm signs the engagement report? Is that the same person who attends the kickoff call? Will that person attend the regulator-engagement meetings if they happen during the engagement? Big-4 and large generalist firms typically have a partner-led intake but a manager-led delivery; specialist firms have partner-led delivery throughout. We are partner-led.

Pricing transparency

Ask: can the firm publish pricing? Can the firm fix the price in writing before kickoff? Vendors that decline both signals are typically priced for negotiation rather than for delivery; the eventual fee tracks the procurement team’s sophistication rather than the work’s scope. We publish prices and fix them in writing.

Crypto-specific threat intelligence — what we monitor on retainer

The crypto-exchange threat-intel function differs materially from generic enterprise threat-intel. Adversary populations, TTPs, infrastructure overlap patterns, and attribution signals are all different. Our retainer threat-intel function monitors specific sources: darknet-marketplace listings of credential databases tagged for exchanges, Telegram-channel chatter on the major Russian-language and Chinese-language threat-actor channels for exchange-specific campaign coordination, GitHub for accidentally-public repository content from exchanges (we monitor 200+ Indian-origin and adjacent organisations on a daily-cycle basis), and on-chain forensics for cluster behaviour suggesting active campaigns against specific exchange wallets. Findings are pushed to clients within 4 hours of discovery; the channel is direct to the security lead with backup notification to the relationship partner. Most retainer clients consider this signal one of the highest-leverage parts of the engagement; it surfaces specific, actionable intelligence that internal threat-intel functions rarely have the bandwidth or specialised network to produce themselves.

To start a crypto exchange engagement, the next step is a thirty-minute scoping call. Engagements typically begin within ten business days due to the depth of architecture review required.