Bitget $387.5M Crypto Heist: Defending Exchange Infrastructure Against Suspected DPRK Hot-Wallet Drainage

Cryptocurrency exchange Bitget has resumed Bitcoin withdrawals after suspending them in response to a breach attributed to suspected North Korean state-sponsored actors. The attackers reportedly made off with more than $350 million — with losses estimated as high as $387.5 million — placing this incident firmly among the largest exchange compromises of the past year.

For defenders, this is not just another headline about stolen crypto. It is a textbook case study in how state-aligned threat actors — most notably DPRK-affiliated groups such as the Lazarus Group constellation tracked by the FBI, CISA, and international partners — systematically target cryptocurrency infrastructure. Exchanges, custodians, and DeFi platforms remain the single highest-value target class for these actors because a successful intrusion converts directly into liquid, difficult-to-recover funds that bankroll sanctioned regimes.

If your organization operates, integrates with, or holds assets on exchange infrastructure — or if you are an MSSP or SOC defending clients in the fintech and digital-asset space — the patterns in this breach should drive immediate detection engineering and hardening work. The techniques behind hot-wallet drainage, withdrawal API abuse, and signing-infrastructure compromise are well understood and, critically, detectable.

Technical Analysis

What Happened

Based on the public reporting, attackers believed to be affiliated with North Korea breached Bitget's systems and exfiltrated over $350 million in cryptocurrency. The exchange suspended Bitcoin withdrawals — a standard containment measure to prevent further drainage and to stop attackers from exploiting the compromised environment to authorize additional transactions — and has since resumed them, indicating the exchange believes the intrusion path has been contained and signing/withdrawal infrastructure rebuilt or re-keyed.

Why Exchanges Get Hit: The DPRK Playbook

While full forensic details of the Bitget intrusion have not been publicly released, DPRK operations against crypto platforms follow a remarkably consistent playbook, documented across the Ronin ($625M), Bybit ($1.5B), Atomic Wallet, CoinsPaid, and Alphapo incidents:

1. Initial access via social engineering or supply chain. DPRK operators are prolific in spear-phishing developers and finance staff, fake job recruiter lures (Operation Dream Job), trojanized trading/wallet applications, and compromising third-party software or service providers with access to the target environment.
2. Persistence and credential theft. Once inside, operators harvest session tokens, SSH keys, cloud IAM credentials, and — critically — credentials and secrets protecting wallet infrastructure (HSM access credentials, MPC key shares, API secrets for hot-wallet services).
3. Reconnaissance of fund flows. Attackers map hot/cold wallet architecture, withdrawal approval workflows, transaction signing services, and multisig/MPC policies. The Bybit breach demonstrated that even multisig front-ends can be subverted by compromising the signing interface so operators approve what appears to be a legitimate transaction.
4. Drainage. Funds are moved via fraudulently signed transactions or abused withdrawal APIs, typically to attacker-controlled addresses, then rapidly laundered through chain-hopping, mixers, and bridge services within hours.

Affected Systems and Exposure Surface

No CVE has been published in connection with this incident, and none should be assumed — the vast majority of exchange compromises do not hinge on a single software vulnerability but on credential theft, signing-process subversion, and operational security failures. The exposure surface defenders must protect includes:

• Hot-wallet services and key material: private keys, MPC key shares, keystore files, wallet.dat, HSM/KMS credentials.
• Withdrawal and signing APIs: internal services that construct, approve, and broadcast transactions.
• Employee endpoints: developers, finance/operations staff, and anyone in the withdrawal approval chain.
• CI/CD and build pipelines: a compromised build can ship a backdoored signing front-end (the Bybit lesson).
• Cloud control planes: IAM keys with KMS/HSM or secrets-manager access.

Exploitation Status

This is confirmed active exploitation with realized losses exceeding $350 million. North Korean threat actors have stolen billions of dollars in cryptocurrency across 2024–2025 campaigns, and the tempo shows no sign of slowing in 2026. Blockchain analytics firms and law enforcement actively track DPRK-linked laundering; organizations should assume any exchange, custodian, or wallet provider is a standing target.

Detection & Response

The detections below target the behavioral core of this attack class: unauthorized access to wallet key material, anomalous withdrawal API usage, and wallet-software execution outside of controlled signing workflows. They are written for environments operating exchange, custodian, or treasury infrastructure — tune thresholds to your baseline.

Sigma Rules

---
title: Suspicious Access to Cryptocurrency Wallet Key Material
id: 8f4e2a71-3b6c-4d9e-a1f2-7c8d9e0f1a2b
status: experimental
description: Detects processes outside an approved wallet/signing baseline accessing wallet key files, keystore directories, or seed material. Core indicator of hot-wallet compromise and key exfiltration consistent with DPRK exchange intrusions.
references:
  - https://www.bleepingcomputer.com/news/security/bitget-resumes-bitcoin-withdrawals-after-3875-million-crypto-heist/
  - https://attack.mitre.org/techniques/T1552/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.credential_access
  - attack.t1552.001
logsource:
  category: file_event
  product: linux
detection:
  selection_paths:
    TargetFilename|contains:
      - '/wallet.dat'
      - '/.bitcoin/'
      - '/.ethereum/keystore/'
      - '/keystore/UTC--'
      - '/secrets/wallet'
      - '/mpc/'
      - 'seedphrase'
      - 'private_key'
  filter_approved_signers:
    Image|endswith:
      - '/bitcoind'
      - '/bitcoin-cli'
      - '/geth'
      - '/wallet-signer'
  condition: selection_paths and not filter_approved_signers
falsepositives:
  - Backup agents and EDR scanners touching keystore paths
  - Legitimate wallet maintenance from admin workstations
level: high
---
title: Wallet CLI Execution from Unusual Parent or User Context
id: 2b7c4d93-5e1a-4f8b-b3c6-9d0e1f2a3b4c
status: experimental
description: Detects execution of cryptocurrency CLI tooling (bitcoin-cli, geth, electrum) by web-server, CI, or non-admin user contexts — a common sign that an intruder who reached a server is probing wallet infrastructure.
references:
  - https://www.bleepingcomputer.com/news/security/bitget-resumes-bitcoin-withdrawals-after-3875-million-crypto-heist/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: linux
detection:
  selection_img:
    Image|endswith:
      - '/bitcoin-cli'
      - '/geth'
      - '/electrum'
      - '/monero-wallet-cli'
  selection_parent:
    ParentImage|endswith:
      - '/nginx'
      - '/apache2'
      - '/node'
      - '/java'
      - '/python'
      - '/php-fpm'
  selection_user:
    User|contains:
      - 'www-data'
      - 'nginx'
      - 'apache'
  condition: selection_img and 1 of selection_parent, selection_user
falsepositives:
  - Application services that legitimately invoke wallet RPCs (restrict by host scope in production)
level: critical
---
title: Mass Withdrawal API Invocation on Exchange Infrastructure
id: 4d9e1f27-8a3b-4c5d-a6e7-1b2c3d4e5f6a
status: experimental
description: Detects abnormally high frequency of withdrawal endpoint calls from a single source or service account, indicative of automated fund drainage after exchange compromise. Baseline your normal withdrawal call rate before deployment.
references:
  - https://www.bleepingcomputer.com/news/security/bitget-resumes-bitcoin-withdrawals-after-3875-million-crypto-heist/
  - https://attack.mitre.org/techniques/T1106/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.impact
  - attack.t1657
logsource:
  category: webserver
  product: linux
detection:
  selection:
    cs-uri-stem|contains:
      - '/api/v1/withdraw'
      - '/api/v2/withdrawal'
      - '/withdraw/create'
      - '/tx/sign'
      - '/transaction/broadcast'
  condition: selection | count() by src_ip > 50
 timeframe: 5m
falsepositives:
  - Market-maker and liquidity-provider integrations with high legitimate withdrawal volume
  - Load balancers masking true source IPs (log X-Forwarded-For)
level: high

KQL — Microsoft Sentinel / Defender

The following query hunts for wallet key-material access and wallet CLI execution across Linux hosts ingested via Syslog, plus anomalous process lineage on endpoints via Defender. Deploy it alongside a watchlist of your approved signing-service binaries and hosts.

let WalletPaths = dynamic(["wallet.dat", "/.bitcoin/", "/.ethereum/keystore", "seedphrase", "private_key", "mpc_share"]);
let WalletBins = dynamic(["bitcoin-cli", "bitcoind", "geth", "electrum", "monero-wallet-cli"]);
let ApprovedSigners = dynamic(["wallet-signer", "hsm-agent"]);
union isfuzzy=true
    (Syslog
    | where TimeGenerated > ago(24h)
    | where SyslogMessage has_any (WalletPaths) or SyslogMessage has_any (WalletBins)
    | where not(SyslogMessage has_any (ApprovedSigners))
    | project TimeGenerated, Computer, HostIP, ProcessName, SyslogMessage),
    (DeviceProcessEvents
    | where TimeGenerated > ago(24h)
    | where FileName has_any (WalletBins)
    | where InitiatingProcessFileName in~ ("nginx", "apache2", "node", "java", "python", "php-fpm", "cmd.exe", "powershell.exe")
       or InitiatingProcessAccountName in~ ("www-data", "nginx", "apache", "iis apppool\\defaultapppool")
    | project TimeGenerated, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessAccountName, AccountName)
| sort by TimeGenerated desc;
// Second hunt: withdrawal API burst detection (requires exchange app logs via Custom Logs / CEF)
CommonSecurityLog
| where TimeGenerated > ago(1h)
| where RequestURL has_any ("/withdraw", "/tx/sign", "/transaction/broadcast")
| summarize RequestCount = count(), DistinctAccounts = dcount(SourceUserID) by SourceIP, RequestURL, bin(TimeGenerated, 5m)
| where RequestCount > 50
| sort by RequestCount desc;

Velociraptor VQL

This artifact hunts endpoints for processes accessing wallet key material and enumerates active outbound connections from wallet-related binaries — useful for scoping whether an intruder touched signing hosts.

-- Hunt: unauthorized access to wallet key material and wallet binary network activity
LET key_access = SELECT Pid, Name, CommandLine, Exe, Username
FROM pslist()
WHERE CommandLine =~ '(wallet\\.dat|keystore|seed|private[_-]?key|mpc)'
  AND NOT Exe =~ '(wallet-signer|bitcoind|geth|hsm-agent)'

LET wallet_net = SELECT Pid, Name, Path, CommandLine,
       netstat() AS Connections
FROM pslist()
WHERE Name =~ '(bitcoin|geth|electrum|wallet|signer)'

SELECT * FROM key_access
UNION ALL
SELECT * FROM wallet_net

Hardening and Verification Script

For Linux-based wallet/signing hosts, this Bash script audits for exposed key material, verifies withdrawal-service configuration, and enforces least-privilege on keystore paths. Run it as part of post-incident verification and quarterly hardening reviews.

#!/bin/bash
# Wallet infrastructure hardening & exposure audit - run as root on signing/hot-wallet hosts
set -euo pipefail

REPORT="/var/log/wallet_hardening_audit_$(date +%Y%m%d).log"
echo "=== Wallet Host Hardening Audit $(date) ===" | tee "$REPORT"

# 1. Locate key material with overly permissive ACLs
echo "[1] Scanning for world-readable key material..." | tee -a "$REPORT"
find / -xdev \( -name "wallet.dat" -o -name "keystore" -o -iname "*private*key*" -o -iname "*seed*" \) \
  -perm /o+r -exec ls -la {} \; 2>/dev/null | tee -a "$REPORT"

# 2. Enforce restrictive permissions on known wallet directories
for DIR in /var/lib/wallet /opt/wallet-signer/keys /home/*/.bitcoin /home/*/.ethereum; do
  if [ -d "$DIR" ]; then
    chmod -R go-rwx "$DIR" && echo "[2] Hardened permissions on $DIR" | tee -a "$REPORT"
  fi
done

# 3. Verify wallet binaries run only as dedicated service accounts
echo "[3] Checking wallet process ownership..." | tee -a "$REPORT"
ps -eo user,comm | grep -Ei 'bitcoind|geth|signer|wallet' | grep -Ev 'walletsvc|signersvc' | tee -a "$REPORT" \
  && echo "WARNING: wallet processes running as unexpected users" | tee -a "$REPORT"

# 4. Audit withdrawal API service accounts for stale/embedded secrets
echo "[4] Checking for secrets in service configs..." | tee -a "$REPORT"
grep -rEl 'api[_-]?key|secret|passphrase' /etc/systemd/system/ /opt/*/config/ 2>/dev/null | tee -a "$REPORT"

# 5. Verify outbound egress restrictions on signing hosts (no arbitrary internet)
echo "[5] Egress rules on this host:" | tee -a "$REPORT"
iptables -L OUTPUT -n -v 2>/dev/null | tee -a "$REPORT" || nft list ruleset 2>/dev/null | tee -a "$REPORT"

echo "=== Audit complete. Review $REPORT and remediate WARNING items immediately. ===" | tee -a "$REPORT"

Remediation

Whether you operate an exchange or defend an organization with crypto exposure, treat this incident class with the following program-level controls:

Immediate (post-incident or preventive verification):

1. Rotate everything the intruder could have touched. Bitget's resumption of withdrawals implies key rotation and infrastructure rebuilding. If you suspect compromise: rotate hot-wallet keys, MPC shares, API secrets, HSM credentials, cloud IAM keys, and employee credentials — in that priority order. Assume any secret readable from a breached host is burned.
2. Suspend withdrawals at the first credible indicator. Bitget's suspension was the correct containment move. Build and rehearse a kill-switch runbook: halt withdrawal queues, freeze signing services, and revoke session/API tokens before forensic certainty is achieved.
3. Rebuild, don't clean. Signing infrastructure and front-ends that construct transactions must be rebuilt from known-good images after compromise. DPRK actors persist aggressively; endpoint cleanup alone is insufficient.

Structural hardening (the controls that actually stop these heists): 4. Minimize hot-wallet balances. Enforce automated sweeps so hot wallets hold only operational minimums; the bulk of assets belong in cold storage with geographically distributed, hardware-backed key material. 5. Enforce out-of-band withdrawal verification. Large or novel withdrawals should require multi-party approval on a channel independent of the system requesting it. The Bybit breach proved that in-band "what you see is what you sign" interfaces can be subverted — use hardware-wallet verification of raw transaction payloads by multiple approvers on segregated machines. 6. Address allowlisting and velocity limits. Restrict withdrawals to pre-registered addresses with time-locked additions, and rate-limit aggregate outflows per hour/day with automatic circuit breakers. 7. Protect the approval chain's endpoints. DPRK initial access overwhelmingly targets people. Deploy phishing-resistant MFA (FIDO2), segregate developer and finance workstations, and apply heightened scrutiny to recruiter contact and unsolicited "job opportunity" lures aimed at staff with signing or treasury access. 8. Secure the build pipeline. Require signed commits, reproducible builds, and independent code review for any component that constructs or displays transaction data. 9. Monitor on-chain in near-real time. Integrate blockchain analytics (Chainalysis, TRM, Elliptic) alerting on movements from your wallet cluster to unknown or sanctioned-attributed addresses, so detection doesn't depend solely on internal telemetry. 10. Coordinate with law enforcement early. Report to the FBI (IC3) and engage blockchain tracing firms immediately upon suspicion — the laundering window is measured in hours, and early attribution improves freeze/recovery odds.

Category Note for Security Teams

If your SOC supports clients in fintech, crypto, or Web3, ensure your detection catalog explicitly covers wallet-infrastructure behaviors (key-material access, signing-service anomalies, withdrawal API bursts). These are not standard in most SIEM content packs, and this incident class demands them.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub