Bitget Breach: $351.6M Stolen by Suspected DPRK Hackers — Hot and Warm Wallet Defense, Detection, and Response Guide

Cryptocurrency exchange Bitget has disclosed that suspected North Korean state-sponsored hackers stole $351.6 million from its hot and warm wallets. This is one of the largest exchange compromises of 2026, and it reinforces a pattern we've tracked for years: DPRK-aligned actors — historically attributed to the Lazarus Group umbrella and its sub-clusters — are no longer just phishing exchange employees. They are systematically targeting the signing layer of crypto operations: the hosts, HSM/KMS configurations, and transaction-approval workflows that turn an authorized-looking withdrawal into an irreversible theft.

Why defenders across every sector should care: the TTPs on display here — long-dwell access, abuse of legitimate cloud key-management services, manipulation of multi-signature approval workflows, and rapid laundering through mixers and cross-chain bridges — are the same techniques DPRK actors use against fintechs, payment processors, and any organization holding digital assets. If you operate or defend wallet infrastructure, treasury systems, or crypto-adjacent services, this incident is your tabletop scenario made real.

This post breaks down the attack chain as we understand it, gives you concrete detections for wallet-signing infrastructure, and provides a hardening and verification script you can run today.

Technical Analysis

What Was Compromised

Bitget disclosed that the attackers accessed both hot wallets (internet-connected wallets used for day-to-day withdrawal processing) and warm wallets (semi-online wallets typically holding larger reserves with additional approval controls). The distinction matters: hot wallet theft usually indicates compromised online signing keys, but warm wallet theft indicates the attackers defeated — or more likely, circumvented through social engineering and workflow abuse — the additional approval gates that warm wallets are supposed to enforce.

The DPRK Crypto-Theft Playbook (Attack Chain)

Based on the disclosure and DPRK actors' well-documented operational patterns against exchanges, the attack chain typically unfolds as follows:

1. Initial Access / Social Engineering: DPRK actors are notorious for fake recruiter lures, bogus job-offer documents, malicious interview 'skills assessments,' and trojanized trading applications targeting exchange and DevOps personnel. The goal is code execution on a workstation with credentials for the wallet operations environment.
2. Credential and Session Theft: Theft of cloud IAM credentials, SSH keys, API tokens, and session cookies — particularly for AWS KMS, HashiCorp Vault, or in-house HSM management consoles used for signing operations.
3. Reconnaissance of the Signing Layer: Enumeration of wallet infrastructure — listing KMS keys, enumerating Vault mounts, identifying the policy engine and approval thresholds governing withdrawals, and mapping which hosts run wallet daemons (bitcoind, geth, solana-validator, proprietary signers).
4. Approval Workflow Abuse or Key Material Access: Rather than 'breaking' cryptography, attackers position themselves as a legitimate signing principal — abusing kms:Decrypt / kms:Sign permissions, injecting into the approval pipeline, or socially engineering the human approvers into signing a malicious transaction that passes policy checks because the request itself looks legitimate.
5. Execution and Laundering: Transactions are broadcast, often batched to stay under per-transaction limits, then rapidly laundered through peel chains, instant swap services, cross-chain bridges, and mixers. Within hours, recovery becomes a law-enforcement problem, not a technical one.

Exploitation Status

This is confirmed, in-the-wild theft with realized financial loss — not a theoretical vulnerability. No CVE has been publicly associated with this incident; the compromise appears rooted in credential theft, social engineering, and abuse of legitimate wallet-signing infrastructure, consistent with MITRE ATT&CK techniques including T1552 (Unsecured Credentials), T1078 (Valid Accounts), T1556 (Modify Authentication Process), T1499-adjacent resource abuse, and financial theft objectives documented under DPRK campaigns (TA444/APT38 overlaps).

The critical defensive insight: there is no patch for this attack class. Defense lives in detection of anomalous signing behavior, separation of duties, transaction policy enforcement independent of the requesting system, and wallet architecture (cold storage ratios, withdrawal rate limits).

Detection & Response

The detections below target the observable behaviors of wallet-infrastructure compromise: credential/key-material access on signing hosts, abuse of cloud key-management APIs, wallet daemons spawning unexpected child processes, and anomalous connectivity to blockchain RPC endpoints.

Sigma Rules

---
title: Wallet Keystore or Key Material File Access by Non-Signer Process
id: 3f8b2c14-7a91-4e55-b6d2-9c1a4f7e8d30
status: experimental
description: Detects processes outside the approved wallet signer tooling reading wallet keystore, seed, or key material files. A strong indicator of DPRK-style key theft from hot/warm wallet hosts.
references:
  - https://www.bleepingcomputer.com/news/security/hackers-steal-3516-million-in-bitget-crypto-exchange-hack/
  - 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_target:
    TargetFilename|contains:
      - '/.ethereum/keystore/'
      - '/.bitcoin/wallet.dat'
      - '/.solana/id.json'
      - '/wallet/keys/'
      - 'seed.txt'
      - '.keystore'
  filter_signers:
    Image|endswith:
      - '/geth'
      - '/bitcoind'
      - '/solana-validator'
      - '/vault'
      - '/signerd'
  condition: selection_target and not filter_signers
falsepositives:
  - Legitimate backup agents reading wallet directories (scope backup service accounts by Image)
level: high
---
title: Cloud CLI Used to Enumerate or Use KMS Signing Keys
id: 8d41a7c2-3b6f-4e18-9a54-2c7d9e1f4b62
status: experimental
description: Detects AWS CLI invocation of KMS or Secrets Manager operations associated with wallet signing keys. DPRK actors abuse stolen cloud credentials to list and use signing keys via legitimate APIs.
references:
  - https://www.bleepingcomputer.com/news/security/hackers-steal-3516-million-in-bitget-crypto-exchange-hack/
  - https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.credential_access
  - attack.t1078.004
  - attack.t1552.005
logsource:
  category: process_creation
  product: windows
detection:
  selection_cli:
    Image|endswith:
      - '\aws.exe'
      - '\vault.exe'
  selection_cmd:
    CommandLine|contains:
      - 'kms list-keys'
      - 'kms describe-key'
      - 'kms sign'
      - 'kms decrypt'
      - 'secretsmanager get-secret-value'
      - 'vault read'
      - 'vault kv get'
  condition: all of selection_*
falsepositives:
  - Cloud administrators performing scheduled key audits (whitelist approved admin accounts and jump hosts)
level: high
---
title: Wallet Daemon Spawning Shell or Script Interpreter
id: c27e91f4-5d83-4a60-b3a7-8e2c6f0d9a41
status: experimental
description: Detects a cryptocurrency node or wallet daemon spawning a shell or script interpreter. Wallet services should never spawn interactive shells; this indicates post-exploitation on the signing host.
references:
  - https://www.bleepingcomputer.com/news/security/hackers-steal-3516-million-in-bitget-crypto-exchange-hack/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/geth'
      - '/bitcoind'
      - '/solana-validator'
      - '/lighthhouse'
      - '/signerd'
      - '/walletd'
  selection_child:
    Image|endswith:
      - '/bash'
      - '/sh'
      - '/zsh'
      - '/python'
      - '/python3'
      - '/perl'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/base64'
  condition: all of selection_*
falsepositives:
  - Custom monitoring wrappers that exec health checks (tune by full Image path and command line)
level: critical

KQL — Microsoft Sentinel / Defender

This hunt assumes CloudTrail (via AWS connector or CEF/Syslog ingestion) and endpoint telemetry. It surfaces anomalous KMS signing/decrypt activity — the core abuse primitive in wallet theft — and correlates it with non-baseline principals or source IPs.

// Hunt: Anomalous KMS Sign/Decrypt usage potentially indicating wallet key abuse
let BaselinePrincipals = dynamic(["arn:aws:iam::123456789012:role/WalletSignerService"]);
let BaselineIPs = dynamic(["10.20.0.0/16"]);
CloudTrailEvents
| where TimeGenerated > ago(14d)
| where EventName in~ ("Decrypt", "Sign", "GetSecretValue", "DescribeKey", "ListKeys")
| extend Principal = tostring(UserIdentityArn), SourceIP = tostring(SourceIpAddress)
| extend IsBaselinePrincipal = iff(Principal has_any (BaselinePrincipals), 1, 0)
| summarize
    CallCount = count(),
    KeyIds = make_set(tostring(RequestParameters.keyId), 20),
    SourceIPs = make_set(SourceIP, 20),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)
    by Principal, EventName, bin(TimeGenerated, 1h), IsBaselinePrincipal
| where IsBaselinePrincipal == 0 or CallCount > 50
| order by TimeGenerated desc;
// Secondary hunt: wallet hosts establishing new outbound connections to blockchain RPC ports or unknown egress
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where RemotePort in (8332, 8333, 8545, 8546, 8899, 30303, 26656)
| where InitiatingProcessFileName !in~ ("geth", "bitcoind", "solana-validator", "signerd")
| summarize Connections = count(), RemoteIPs = make_set(RemoteIP, 25)
    by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, bin(TimeGenerated, 1h)
| order by Connections desc;

Velociraptor VQL

Use this artifact across your Linux wallet/signing fleet to find shells or interpreters spawned by wallet daemons, and unexpected listeners/connections to blockchain RPC ports.

-- Hunt: Wallet daemon children and anomalous RPC egress on signing hosts
LET daemon_children = SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE get(pid: Ppid).Name =~ '(geth|bitcoind|solana|signerd|walletd)'
  AND Name =~ '(bash|sh|zsh|python|perl|curl|wget|nc|socat)'

LET rpc_conns = SELECT Pid, Name, CommandLine, LocalAddr, RemoteAddr, Status
FROM netstat()
WHERE (RemoteAddr =~ ':(8332|8333|8545|8546|8899|30303|26656)'
   OR LocalAddr =~ ':(8332|8333|8545|8546|8899|30303|26656)')
  AND Name !~ '(geth|bitcoind|solana|signerd|walletd|monitor)'

SELECT 'daemon_child' AS Finding, Pid, Ppid, Name, CommandLine, NULL AS RemoteAddr FROM daemon_children
UNION ALL
SELECT 'rpc_connection' AS Finding, Pid, NULL AS Ppid, Name, CommandLine, RemoteAddr FROM rpc_conns

Verification & Hardening Script (Bash)

Run on Linux wallet/signing hosts to audit key-material file permissions, unexpected KMS usage in CloudTrail, and daemons running with excessive privilege. Review output before making changes in production.

#!/usr/bin/env bash
# Security Arsenal - Wallet Signing Host Verification & Hardening Audit
# Run as root on hot/warm wallet infrastructure. Read-only audit by default.
set -euo pipefail

echo "=== [1] Wallet keystore permissions and ownership ==="
for d in /home/*/.ethereum/keystore /root/.ethereum/keystore /var/lib/wallet /opt/signer /home/*/.bitcoin; do
  [ -d "$d" ] && ls -la "$d" && stat -c '%a %U:%G %n' "$d"
done
# Flag anything world-readable: key material must be 0600/0400 owned by the signer service account
find / -xdev \( -name '*.keystore' -o -name 'wallet.dat' -o -name 'id.json' \) -perm -o+r 2>/dev/null | while read -r f; do
  echo "[ALERT] World-readable key material: $f"
done

echo "=== [2] Wallet daemons running as root (should be dedicated service accounts) ==="
ps -eo user,pid,comm,args | grep -E '(geth|bitcoind|solana-validator|signerd|walletd)' | grep -v grep | awk '$1=="root"{print "[ALERT] daemon as root: "$0}'

echo "=== [3] Suspicious child processes of wallet daemons (live check) ==="
for pid in $(pgrep -f 'geth|bitcoind|solana-validator|signerd|walletd'); do
  ps --ppid "$pid" -o pid,comm,args 2>/dev/null | grep -E '(bash|sh|python|perl|curl|wget|nc)' && echo "[ALERT] suspicious child of PID $pid"
done

echo "=== [4] KMS/Secrets access audit (last 24h, requires aws cli + CloudTrail access) ==="
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=Decrypt \
  --start-time "$(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --max-results 50 --query 'Events[].{Time:EventTime,User:Username,Event:EventName}' --output table 2>/dev/null || echo "[INFO] CloudTrail lookup unavailable - run from a host with read-only AWS audit credentials"

echo "=== [5] Outbound connections to blockchain RPC ports by unexpected processes ==="
ss -tlnp 2>/dev/null | grep -E ':(8332|8545|8546|8899|30303) ' | grep -vE '(geth|bitcoind|solana|signerd)' || echo "[OK] No unexpected RPC listeners"
ss -tnp 2>/dev/null | grep -E ':(8332|8333|8545|8546|8899|30303|26656)' | grep -vE '(geth|bitcoind|solana|signerd|walletd)' || echo "[OK] No unexpected RPC egress"

echo "=== [6] Withdrawal policy / signer config integrity ==="
for cfg in /etc/signer/*.conf /opt/signer/config* /var/lib/wallet/policy*; do
  [ -f "$cfg" ] && stat -c '%y %U %n' "$cfg" && echo "[INFO] Verify last-modified above against change-management records"
done

echo "=== Audit complete. Investigate every [ALERT] line before proceeding. ==="

Remediation & Hardening Guidance

There is no CVE and no patch for this incident — remediation is architectural and operational. Prioritize the following, in order:

1. Assume signing-key exposure; rotate everything. If you suspect any compromise of wallet infrastructure, rotate all KMS/HSM keys, API tokens, IAM credentials, and SSH keys associated with signing operations. Rotate the approvers' credentials too — DPRK actors persist through the humans, not just the hosts.
2. Enforce cold-storage ratios and withdrawal rate limits. No hot wallet should hold more than is operationally required for ~24 hours of withdrawal volume. Implement hard daily withdrawal ceilings at the signing layer — not just the application layer — so even a fully authenticated attacker cannot drain reserves in one session. A $351.6M loss implies limits either didn't exist or were bypassed at the policy engine.
3. Make transaction policy independent of the requesting system. The approval workflow must validate destination addresses against allowlists, enforce time delays (24–72h) for new addresses, and require out-of-band human approval on separate hardware for anything above defined thresholds. An attacker who controls the request pipeline must not be able to also satisfy the approval pipeline.
4. Constrain KMS/HSM permissions to the minimum. Signing service roles should have kms:Sign on specific key ARNs and nothing else. Deny kms:Decrypt, kms:DisableKey, kms:ScheduleKeyDeletion, and kms:PutKeyPolicy to runtime principals. Alert on every DescribeKey/ListKeys from non-audit principals — enumeration precedes theft.
5. Isolate signing hosts. Dedicated subnets, no internet egress except required blockchain RPC endpoints (egress allowlist), no inbound access except from a hardened jump host, EDR deployed, and shells/script interpreters blocked via application control (e.g., allowlisting) on the signer fleet.
6. Monitor for the laundering phase. Integrate blockchain analytics (Chainalysis, TRM, Elliptic, or open-source equivalents) into your SOC. Alert on transactions from your known wallet addresses to newly seen addresses, mixing services, or instant-swap services. Early detection here is the difference between a frozen-asset recovery and a total loss — law enforcement (FBI, and international partners) has had real success freezing DPRK-laundered funds when notified within hours.
7. Counter the social-engineering vector. DPRK operators target your people first. Screen job candidates rigorously (DPRK IT workers use stolen identities to infiltrate exchanges as employees), block unsolicited recruiter contact to engineering staff from reaching endpoints with wallet access, and treat any 'skills assessment' executable as hostile by policy.
8. If you are breached: engage IR immediately and preserve everything. Snapshot signing hosts before remediation, preserve CloudTrail/Vault audit logs (attackers routinely attempt to purge them), and contact law enforcement and your blockchain analytics partner in the first hours. The laundering clock starts the moment the transaction confirms.

For further defensive guidance, review the FBI's joint advisories on DPRK cryptocurrency theft operations and CISA's guidance on North Korean state-sponsored cyber threats at cisa.gov.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub