On September 24, 2026, at 18:31 UTC, cryptocurrency exchange Bitget detected unauthorized transfers from a subset of its hot and warm wallets. The exchange attributes the theft — totaling $351.6 million — to suspected North Korean state-sponsored threat actors, and states that the root cause was a compromise of backend infrastructure, not a flaw in wallet cryptography or the blockchain itself. Cold wallets and the majority of platform assets were reportedly unaffected.
This incident is the latest and one of the largest in a years-long campaign by DPRK-aligned groups (overlapping with activity tracked as Lazarus Group, APT38, TraderTraitor, and Jade Sleet) targeting cryptocurrency exchanges, custodians, and Web3 firms to fund sanctioned weapons programs. The defensive lesson is consistent across every one of these incidents: the attackers did not break the blockchain — they broke the people, endpoints, and backend systems that hold the keys.
If you operate exchange infrastructure, custody services, fintech payment rails, or any environment where backend systems can authorize high-value transactions, this post breaks down the attack pattern and delivers concrete detection engineering and hardening guidance.
What Happened
Per Bitget's public statement on X:
"At 18:31 UTC on September 24, 2026, Bitget's security systems identified unauthorized transfers involving a limited number of hot wallets... Bitget's cold wallets and the overwhelming majority of platform assets remain [secure]."
Key facts as reported:
- Loss: $351.6 million across hot and warm wallets
- Attribution: Suspected North Korean threat actors
- Root cause: Backend compromise — i.e., attacker access to internal systems that orchestrate or sign transactions, rather than exploitation of a smart contract or wallet protocol
- Impact scope: Cold (offline, air-gapped or HSM-locked) storage was not affected, consistent with architectural segmentation working as designed
The pattern mirrors prior DPRK exchange intrusions (Bybit, DMM Bitcoin, WazirX, Atomic Wallet, CoinsPaid/Alphapo): initial access via social engineering, malicious recruiter lures, trojanized trading/DeFi applications, or compromised third-party vendors; lateral movement into transaction-signing infrastructure; then a burst of unauthorized withdrawals laundered through mixers, cross-chain bridges, and OTC brokers within hours.
No CVE has been disclosed for this incident, and none should be assumed. This was an intrusion against operational infrastructure — treat it as a TTP problem, not a patch problem.
Technical Analysis: How These Intrusions Typically Unfold
Because Bitget has not (yet) published a full technical post-mortem, the following is the defender's model of the DPRK exchange-compromise playbook, mapped to MITRE ATT&CK, based on repeated observed campaigns:
1. Initial Access (T1566, T1078, T1195)
- Spearphishing with malicious lures: fake job offers from "recruiters" delivering trojanized PDF readers or Node.js/Python coding assessments
- Trojanized legitimate software: compromised installers for trading tools, crypto wallets, or meeting apps (the 3CX supply-chain model)
- Compromised third-party vendors or developers with VPN/CI-CD access to exchange backend environments
2. Persistence & Credential Theft (T1059, T1003, T1552)
- Deployment of lightweight cross-platform malware (macOS and Linux endpoints are heavily targeted in this sector, not just Windows)
- Credential harvesting from developer workstations: SSH keys, cloud IAM tokens, secrets in
.envfiles, browser-stored credentials for admin consoles - Abuse of CI/CD pipelines (GitHub Actions, GitLab runners, Jenkins) to reach production signing services
3. Target: The Signing Path (T1657, T1557)
The crown jewels are the components that authorize outbound transactions:
- Hot wallet private keys or key shards
- MPC (multi-party computation) co-signing services
- Withdrawal approval APIs and their service accounts
- Transaction queues that can be manipulated so a fraudulent transfer appears as a routine payout (the Bybit-style "blind signing" lesson: the interface shows one thing, the signed payload is another)
4. Execution: Wallet Draining (T1041, T1020)
- Unauthorized transfers fired in a short burst, often timed outside core staffing hours
- Rapid laundering: chain-hopping across bridges, conversion through decentralized exchanges, deposits into mixing services
Exploitation Status
Confirmed active, in-the-wild theft with $351.6M in realized losses. This is not theoretical. DPRK financial-motivated intrusion activity against the crypto sector is persistent, well-resourced, and accelerating.
Detection & Response
The detections below focus on observable behaviors that precede or accompany wallet-draining intrusions: anomalous process execution on wallet/signing infrastructure, credential-access tooling on backend hosts, and suspicious outbound activity from systems that should have a tightly constrained network profile. Tune thresholds to your environment before production deployment.
Sigma Rules
---
title: Credential Dumping Tool Execution on Backend or Signing Infrastructure
id: 8f2c1a47-3b9e-4d51-a6c2-7e8f4b1d9a30
status: experimental
description: Detects execution of common credential access tooling on servers hosting wallet signing, withdrawal processing, or exchange backend services. DPRK actors routinely harvest SSH keys, tokens, and service credentials before reaching signing infrastructure.
references:
- https://attack.mitre.org/techniques/T1003/
- https://thehackernews.com/2026/09/bitget-says-suspected-north-korean.html
author: Security Arsenal
date: 2026/09/25
tags:
- attack.credential_access
- attack.t1003
logsource:
category: process_creation
product: windows
detection:
selection_img:
Image|endswith:
- '\mimikatz.exe'
- '\procdump.exe'
- '\nanodump.exe'
- '\pypykatz.exe'
- '\rundll32.exe'
selection_cli:
CommandLine|contains:
- 'sekurlsa::'
- 'lsadump::'
- 'comsvcs.dll'
- 'MiniDump'
- 'lsass'
condition: selection_img and selection_cli
falsepositives:
- Legitimate LSASS dumps by approved EDR/forensics tooling
- Admin memory diagnostics
level: high
---
title: Suspicious Shell or Script Execution on Linux Wallet Signing Hosts
id: 4d7e9b21-6a3f-4c88-b2d5-9f1a3c6e8b42
status: experimental
description: Detects interactive shells, base64-decoded payloads, and living-off-the-land downloaders spawned by wallet daemon, node, or signing service processes on Linux infrastructure. Backend services should rarely spawn shells; this is a strong intrusion indicator on transaction-signing hosts.
references:
- https://attack.mitre.org/techniques/T1059/004/
- https://thehackernews.com/2026/09/bitget-says-suspected-north-korean.html
author: Security Arsenal
date: 2026/09/25
tags:
- attack.execution
- attack.t1059.004
- attack.t1105
logsource:
category: process_creation
product: linux
detection:
selection_parent:
ParentImage|endswith:
- '/bitcoind'
- '/geth'
- '/node'
- '/java'
- '/python'
- '/python3'
- '/dockerd'
- '/containerd'
selection_child:
Image|endswith:
- '/bash'
- '/sh'
- '/curl'
- '/wget'
- '/nc'
- '/ncat'
- '/socat'
- '/base64'
- '/python'
- '/python3'
condition: selection_parent and selection_child
falsepositives:
- Wallet node health-check scripts invoking curl
- Container orchestration agents
level: high
---
title: Outbound Connection from Signing or Wallet Host to Unapproved Destination
id: 2b6a8d13-9c4e-4f71-a3b8-5d2e7f9c1a64
status: experimental
description: Detects network connections from wallet/signing backend processes to rare external destinations. Signing hosts should communicate only with a strict allowlist (chain RPC endpoints, internal services); new outbound destinations can indicate C2 or exfiltration during a wallet-draining intrusion.
references:
- https://attack.mitre.org/techniques/T1071/
- https://thehackernews.com/2026/09/bitget-says-suspected-north-korean.html
author: Security Arsenal
date: 2026/09/25
tags:
- attack.command_and_control
- attack.t1071
- attack.exfiltration
logsource:
category: network_connection
product: linux
detection:
selection:
Image|endswith:
- '/bitcoind'
- '/geth'
- '/node'
- '/java'
filter_allowlist:
DestinationIp|cidr:
- '10.0.0.0/8'
- '172.16.0.0/12'
- '192.168.0.0/16'
condition: selection and not filter_allowlist
falsepositives:
- Blockchain peer-to-peer gossip traffic on daemon ports (restrict rule to signing/API processes rather than P2P daemons if noisy)
- Package updates from repo mirrors
level: medium
KQL (Microsoft Sentinel / Defender)
The following hunt assumes Syslog/CEF ingestion from Linux backend infrastructure plus Defender for Endpoint telemetry on corporate endpoints — the two planes DPRK actors traverse in exchange intrusions. It looks for wallet-daemon and backend service processes spawning shells or downloaders, and for signing-adjacent hosts making rare outbound connections.
// Hunt 1: Backend/wallet service processes spawning shells or downloaders (Linux via Syslog + MDE)
let WalletParents = dynamic(["bitcoind","geth","node","java","dockerd","containerd"]);
let SuspiciousChildren = dynamic(["bash","sh","curl","wget","nc","ncat","socat","base64"]);
union isfuzzy=true
(Syslog
| where Facility == "user" or SyslogMessage has "execve"
| extend Parent = extract(@"PPID comm=(\w+)", 1, SyslogMessage),
Child = extract(@"comm=(\w+)", 1, SyslogMessage)
| where Parent in~ (WalletParents) and Child in~ (SuspiciousChildren)
| project TimeGenerated, Computer, Parent, Child, SyslogMessage),
(DeviceProcessEvents
| where InitiatingProcessFileName in~ (WalletParents)
| where FileName in~ (SuspiciousChildren)
or ProcessCommandLine has_any ("base64 -d", "curl http", "wget http", "| sh", "| bash")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, AccountName)
| order by TimeGenerated desc;
// Hunt 2: Rare outbound destinations from signing/backend hosts (last 24h vs 14d baseline)
let Baseline =
DeviceNetworkEvents
| where TimeGenerated > ago(14d) and TimeGenerated < ago(1d)
| where InitiatingProcessFileName in~ ("node","java","bitcoind","geth","python")
| summarize by RemoteIP;
DeviceNetworkEvents
| where TimeGenerated > ago(24h)
| where InitiatingProcessFileName in~ ("node","java","bitcoind","geth","python")
| where RemoteIP !in (toscalar(Baseline))
| where RemoteIP !startswith "10." and RemoteIP !startswith "192.168." and RemoteIP !startswith "172.16."
| summarize Connections=count(), FirstSeen=min(TimeGenerated), Ports=make_set(RemotePort)
by DeviceName, InitiatingProcessFileName, RemoteIP, RemoteUrl
| order by FirstSeen desc;
// Hunt 3: Withdrawal-burst anomaly — alert when outbound transaction volume per hour exceeds 3x the 7-day hourly p95
// (Requires wallet/exchange telemetry ingested as a custom log table, e.g. WithdrawalEvents_CL)
WithdrawalEvents_CL
| where TimeGenerated > ago(1d)
| summarize HourlyVolume = sum(AmountUsd_d), TxCount = count() by bin(TimeGenerated, 1h)
| join kind=inner (
WithdrawalEvents_CL
| where TimeGenerated > ago(7d)
| summarize HourlyVolume = sum(AmountUsd_d) by bin(TimeGenerated, 1h)
| summarize P95 = percentile(HourlyVolume, 95)
) on $left.Dummy == $right.Dummy // replace with cross-join pattern per your schema
| where HourlyVolume > 3 * P95
| project TimeGenerated, HourlyVolume, TxCount;
Hunts 1 and 2 are directly actionable against the endpoint/backend compromise phase. Hunt 3 is the control that actually limits losses: a velocity-based tripwire on withdrawal volume, which is how Bitget's own systems reportedly caught this. If you operate exchange infrastructure and you do not have a withdrawal-velocity alert with automated freeze capability, build it this week.
Velociraptor VQL
Use this artifact across backend Linux and macOS hosts (and Windows endpoints) to surface persistence and credential-access staging typical of DPRK exchange intrusions: recently modified SSH keys, unexpected launch agents/systemd units, and processes with suspicious command lines.
-- Bitget/DPRK intrusion hunt: persistence, SSH key tampering, suspicious processes
-- Persistence: systemd units and launch agents modified in the last 7 days
SELECT FullPath, Mtime, Size,
read_file(filename=FullPath, length=4096) AS UnitSnippet
FROM glob(globs=['/etc/systemd/system/*.service',
'/usr/lib/systemd/system/*.service',
'/Library/LaunchDaemons/*.plist',
'/Library/LaunchAgents/*.plist',
os.path.expanduser('~') + '/Library/LaunchAgents/*.plist'])
WHERE Mtime > now() - 7 * 24 * 3600
AND (UnitSnippet =~ '(curl|wget|bash -c|base64|/tmp/|/dev/shm/)' )
-- SSH authorized_keys / known_hosts modified recently (key theft or implant staging)
SELECT FullPath, Mtime, Size
FROM glob(globs=[os.path.expanduser('~') + '/.ssh/authorized_keys',
os.path.expanduser('~') + '/.ssh/id_*',
'/root/.ssh/authorized_keys'])
WHERE Mtime > now() - 7 * 24 * 3600
-- Processes with suspicious command lines on backend hosts
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(base64 -d|curl .*(http|https)|wget .*(http|https)|nc -|ncat |/dev/tcp/|chmod \+x)'
OR Exe =~ '(/tmp/|/dev/shm/|/var/tmp/)'
ORDER BY CreateTime DESC
Remediation / Hardening Script
This Bash script is for Linux backend and signing hosts. It audits for the most common intrusion artifacts: recently modified SSH keys, suspicious systemd units, unexpected listening services, and processes executing from temporary filesystems. Run it across your wallet-adjacent fleet immediately and bake the checks into continuous compliance monitoring.
#!/usr/bin/env bash
# bitget-dprk-triage.sh — Rapid triage for exchange backend/signing hosts
# Checks: SSH key tampering, rogue persistence, tmp-exec processes, egress anomalies
set -euo pipefail
OUT="/var/tmp/triage_$(hostname)_$(date +%Y%m%d%H%M%S).log"
echo "=== Triage started $(date -u) ===" | tee "$OUT"
# 1) SSH keys modified in the last 14 days
echo -e "\n[1] Recently modified SSH material:" | tee -a "$OUT"
find /root/.ssh /home/*/.ssh -type f \( -name 'authorized_keys' -o -name 'id_*' \) \
-mtime -14 -ls 2>/dev/null | tee -a "$OUT" || true
# 2) Systemd units created/modified in the last 14 days
echo -e "\n[2] Recently modified systemd units:" | tee -a "$OUT"
find /etc/systemd/system /usr/lib/systemd/system -name '*.service' \
-mtime -14 -ls 2>/dev/null | tee -a "$OUT" || true
grep -rEl 'curl|wget|base64|/tmp/|/dev/shm/' /etc/systemd/system/*.service 2>/dev/null | tee -a "$OUT" || true
# 3) Processes executing from volatile filesystems
echo -e "\n[3] Processes running from /tmp, /dev/shm, /var/tmp:" | tee -a "$OUT"
for pid in $(ls /proc | grep -E '^[0-9]+$'); do
exe=$(readlink "/proc/$pid/exe" 2>/dev/null || true)
case "$exe" in
/tmp/*|/dev/shm/*|/var/tmp/*) echo "PID $pid -> $exe" | tee -a "$OUT";;
esac
done
# 4) Cron persistence review
echo -e "\n[4] Cron entries (system + users):" | tee -a "$OUT"
cat /etc/crontab 2>/dev/null | tee -a "$OUT" || true
ls -la /etc/cron.d/ /var/spool/cron/ 2>/dev/null | tee -a "$OUT" || true
# 5) Outbound connections from wallet/backend service users
echo -e "\n[5] Established outbound connections (non-RFC1918):" | tee -a "$OUT"
ss -tupn state established 2>/dev/null | \
grep -vE '10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01])\.' | tee -a "$OUT" || true
# 6) Enforce SSH hardening on signing hosts
echo -e "\n[6] Applying SSH hardening (password auth off, root login off):" | tee -a "$OUT"
SSHD=/etc/ssh/sshd_config
cp "$SSHD" "${SSHD}.bak.$(date +%s)"
sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' "$SSHD"
sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' "$SSHD"
systemctl reload sshd 2>/dev/null || systemctl reload ssh 2>/dev/null || true
echo -e "\n=== Triage complete. Output: $OUT ===" | tee -a "$OUT"
echo "REVIEW the log before assuming clean; escalate anomalies to IR immediately."
Remediation & Hardening Priorities
There is no vendor patch to apply here — this is architectural and operational defense. Prioritize the controls that break the DPRK exchange-intrusion kill chain:
- Withdrawal velocity tripwires with automated freeze. Enforce hard daily/hourly volume ceilings on hot wallets, and auto-halt withdrawals (with human re-authorization) when volume exceeds a statistical baseline. This is the single control that converts a $351M loss into a $5M loss.
- Shrink hot wallet exposure. Hot wallets should hold only what liquidity demands — typically low single-digit percentages of total assets. Bitget's cold storage isolation limited this incident; validate your own segregation with drills, not diagrams.
- Eliminate blind signing. Every transaction signed by an MPC co-signer or HSM must have its full payload (destination address, amount, chain) independently verified by a second system that does not share a trust path with the requester. Display-what-you-sign is mandatory.
- Harden the signing path end-to-end. Dedicated, allowlisted egress on signing hosts; no general-purpose shells or package managers; secrets in HSM/KMS only — never in
.envfiles, CI variables on developer machines, or browser credential stores. - Hunt your developer and CI/CD plane. DPRK initial access overwhelmingly targets employees via recruiter lures and trojanized tooling. Enforce phishing-resistant MFA (FIDO2), restrict what CI runners can reach in production, and alert on OAuth grants and new SSH keys in code repositories.
- Third-party and supply-chain review. Enumerate every vendor, SDK, and contractor with backend or deployment access. The 3CX incident demonstrated DPRK willingness to compromise a supplier to reach exchange infrastructure.
- Prepare laundering response runbooks. Pre-establish contacts with major exchanges, stablecoin issuers (freeze capability), blockchain analytics firms, and law enforcement. In these incidents, funds move through bridges and mixers within hours — response speed determines recovery.
- Monitor DPRK advisories. Track FBI/CISA advisories on DPRK crypto-sector activity and OFAC-designated wallet addresses; ingest published wallet IOCs into your deposit-screening controls.
Bottom Line
Bitget's $351.6M loss is not an anomaly — it is the current state of play. North Korean operators treat cryptocurrency infrastructure as a revenue pipeline, and they consistently win by compromising the operational layer around the keys, not the keys themselves. If your detection strategy is focused on the blockchain and not on the endpoints, CI/CD systems, and signing services behind it, you are watching the wrong plane. Build the tripwires, segment the signing path, and drill the freeze procedure — because in these incidents, minutes are money.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.