✅ 1. Penetration Testing Charter Template – Crypto Exchange
Document Owner: CISO / Head of Security
Version: 1.0
Effective Date: [Date]
Review Cadence: Annual or after major regulatory/technical shifts
1. Purpose
To define the scope, authority, standards, and expectations for all internal and external penetration testing activities across Binance products, infrastructure, and digital asset systems.
2. Objectives
- Identify exploitable vulnerabilities before adversaries do
- Validate the effectiveness of defensive controls (detection, prevention, response)
- Fulfill regulatory and compliance obligations (e.g., SOC 2, VASP licensing)
- Build stakeholder trust through proactive security validation
3. Scope
| Category | In Scope | Out of Scope |
|---|---|---|
| Applications | Web/mobile apps (Spot, Futures, Wallet, Binance Pay), APIs, admin dashboards | Third-party vendor apps not integrated via Binance auth |
| Infrastructure | Cloud (AWS/GCP), Kubernetes clusters, CI/CD pipelines, internal tools | Physical data centers managed by cloud providers |
| Blockchain | Smart contracts (BSC, BEP-20), staking protocols, bridge oracles | Public blockchains (Ethereum, Solana) core protocol |
| Social/Physical | Phishing simulations, vishing, badge cloning (with legal approval) | Unauthorized physical intrusion |
⚠️ Explicit Exclusions:
- Denial-of-Service (DoS) attacks that impact production availability
- Social engineering of customers (only employees permitted)
- Exploitation that moves real funds (all tests on testnet or sandbox with synthetic assets)
4. Authority
- Testing authorized under written engagement letters or internal red team mandates
- Testers must comply with the Rules of Engagement (RoE)
- All findings are privileged and confidential
5. Standards & Methodologies
- OWASP Web Security Testing Guide (WSTG)
- PTES (Penetration Testing Execution Standard)
- MITRE ATT&CK (with Crypto Overlay)
- Smart Contract Security Verification Standard (SCSVS)
6. Roles & Responsibilities
| Role | Responsibility |
|---|---|
| Security Team | Define scope, approve RoE, coordinate access |
| Product/Eng Teams | Provide test environments, remediate findings |
| External Testers | Execute tests, report findings, retest fixes |
| Internal Audit | Validate testing coverage and closure |
7. Reporting & Remediation
- Full technical report within 5 business days of test completion
- Executive summary for CISO & Risk Committee
- Critical/high findings tracked in GRC with SLA-based remediation:
- Critical: 72 hours
- High: 7 days
- Retesting required for all critical/high findings
8. Legal & Compliance
- All testing complies with local laws (e.g., UAE Cybercrime Law, MiCA Art. 61)
- No data exfiltration beyond PoC necessity
- Findings may be shared with regulators under audit rights
📊 2. Vulnerability Risk Scoring Matrix – Crypto-Specific
Based on CVSS 4.0, enhanced with crypto business context.
Base Risk Score = (Technical Severity × Business Impact Multiplier)
| Technical Severity (CVSS-like) | Criteria |
|---|---|
| Critical (9.0–10.0) | Info leaks, CSRF, and misconfigurations with limited impact |
| High (7.0–8.9) | AuthZ bypass, sensitive data leak, transaction tampering |
| Medium (4.0–6.9) | Info leaks, CSRF, misconfigurations with limited impact |
| Low (<4.0) | UI bugs, non-sensitive logging |
Crypto-Specific Business Impact Multipliers
| Asset/System | Multiplier | Rationale |
|---|---|---|
| Hot Wallet / Custody System | ×2.0 | Direct fund loss = existential risk |
| User Withdrawal API | ×1.8 | Enables mass fund drainage |
| KYC / Identity Database | ×1.5 | Regulatory fines + reputational harm |
| Smart Contract (Live) | ×1.7 | Immutable; exploit = irreversible loss |
| Trading Engine | ×1.6 | Market manipulation = financial + legal risk |
| Internal Admin Portal | ×1.4 | Privileged access = lateral movement risk |
| Marketing Website | ×1.0 | Low direct asset impact |
Final Risk Rating Example
- Vulnerability: Missing signature validation in the staking contract
- Technical: High (8.1)
- Multiplier: ×1.7 (smart contract)
- Adjusted Score: 13.8 → Treated as Critical
📌 Remediation SLAs based on Adjusted Score:
- ≥12.0 → Critical: 24–72 hrs
- 8.0–11.9 → High: 7 days
- 4.0–7.9 → Medium: 30 days
- <4.0 → Low: Best effort
🎭 3. Red Team Scenario Playbook – Wallet Infrastructure
Scenario: “Adversary compromises employee workstation → escalates to cloud vault → attempts fund exfiltration from hot wallet”
Objective
Test end-to-end detection and response across endpoint, identity, cloud, and custody layers.
Threat Actor Profile
- Motivation: Financial gain
- TTPs: Phishing → credential theft → privilege escalation → cloud IAM abuse → wallet access
Phases & Techniques
| Phase | Technique | Tools | Defense Test |
|---|---|---|---|
| Initial Access | Spear-phishing with Binance-branded 2FA bypass lure | GoPhish, Evilginx2 | Email gateway, EDR, user training |
| Execution | Malicious macro → C2 beacon | Cobalt Strike, Sliver | EDR detection, network egress filtering |
| Persistence | Scheduled task, Golden SAML | Rubeus, Mimikatz | SIEM anomaly detection |
| Privilege Escalation | Kerberoasting → Domain admin | Impacket | PAM enforcement (CyberArk), just-in-time access |
| Cloud Access | Exfiltrated AWS keys → IAM role chaining | AWS CLI, Pacu | CloudTrail alerting, SCP restrictions |
| Vault Access | Attempt to retrieve wallet signing keys from HashiCorp Vault | Vault API abuse | Vault audit logs, MFA for secret access |
| Fund Movement | Construct unsigned withdrawal TX → sign via compromised MPC node (in testnet) | Custom Python script | Transaction simulation block, withdrawal whitelisting |
| Exfiltration | Send testnet funds to attacker-controlled address | Web3.py | On-chain monitoring (Chainalysis Reactor) |
Success Criteria (for Red Team)
- Achieve credential access to the cloud vault
- Construct a valid withdrawal transaction (even if blocked at broadcast)
- Evade detection for >4 hours
Blue Team Validation Points
- Alert generated on anomalous login (impossible travel)
- PAM system blocks unsanctioned vault access
- SOAR playbook auto-isolates the compromised host
- On-chain monitor flags testnet outflow
Rules of Engagement
- No production fund movement
- All actions logged and reversible
- Pause if high-fidelity alert fires (collaborative “purple team” moment)
Post-Engagement
- Tabletop debrief with Security, Wallet Eng, and IR teams
- Update detection rules and PAM policies
- Feed findings into the vulnerability scoring matrix
