Bitget $387.5M Breach: Defending Against Zero-Days in Third-Party Security Products

On Wednesday, cryptocurrency exchange Bitget confirmed what many of us in the DFIR community have been warning about for years: the attackers behind last week's $387.5 million theft didn't breach the exchange through a phishing email or a misconfigured S3 bucket. They walked in through the very products Bitget deployed to protect itself.

Citing ongoing investigation findings from blockchain forensics firm SlowMist, Bitget stated that the investigation "identified malicious activity involving third-party security products, including an unpatched vulnerability, and recovered a customized tool used by the attacker." Read that sentence again. An unpatched vulnerability — in a security product — was the initial access vector for one of the largest cryptocurrency thefts of 2026. The attacker then deployed a purpose-built tool against the compromised environment, indicating pre-planning and target-specific tooling, not opportunistic smash-and-grab.

This is not a Bitget problem. This is an industry problem. Every enterprise that has spent the last decade layering EDR, email gateways, VPN concentrators, and monitoring agents onto their estate has simultaneously been expanding their attack surface with privileged, deeply-integrated, internet-adjacent software that often runs with the highest privileges in the environment. If your threat model doesn't treat your security tooling as Tier-0 attack surface, the Bitget incident is your wake-up call.

Technical Analysis: Anatomy of the Attack

What We Know

Based on Bitget's disclosure and SlowMist's investigation findings:

• Initial access vector: An unpatched vulnerability in a third-party security product deployed in Bitget's environment. The specific vendor and product have not been publicly named — a common practice while coordinated disclosure and patching are underway, and defenders should expect attribution details to emerge.
• Attacker tooling: SlowMist recovered a customized tool used by the attacker. The existence of bespoke tooling strongly suggests a targeted operation — consistent with the financially motivated, high-sophistication actors (including DPRK-nexus groups) that have historically targeted cryptocurrency exchanges.
• Impact: $387.5 million in cryptocurrency stolen. This scale of loss implies the attackers achieved deep access — almost certainly reaching hot wallet infrastructure, signing services, or the operational personnel/systems that control them.
• Exploitation status: Confirmed active exploitation in the wild. This is not a theoretical or proof-of-concept scenario.

Why Security Products Are the Perfect Foothold

From a defender's perspective, security products occupy a uniquely dangerous position in the trust hierarchy:

1. Privilege concentration. EDR agents, monitoring daemons, and email/web security gateways run as SYSTEM, root, or with kernel-level drivers. A single memory-corruption or auth-bypass flaw in these components hands the attacker the keys without requiring privilege escalation.
2. Trusted network position. Security appliances sit inline on traffic (email gateways, WAFs, VPNs) or hold broad network reachability (management consoles). Compromising one often means compromising visibility itself — the attacker can blind or mislead the SOC from inside the sensor.
3. Patch latency. Security tooling is notoriously slow to patch in production. Teams fear breaking detections, voiding support agreements, or destabilizing endpoints. That operational caution creates exactly the window an unpatched flaw needs.
4. Monitoring blind spots. Most organizations do not monitor their security products the way they monitor servers. Agent service stops, unexpected child processes from MsMpEng.exe, EDR service processes, or gateway daemons frequently generate no alerts at all — because the very system that would alert is the one being tampered with.

Probable Attack Chain

While full technical details remain under investigation, the disclosed facts support a chain consistent with recent exchange-targeting operations:

1. Reconnaissance: Identification of the third-party security product and version in use (via internet scanning, job postings, vendor case studies, or supplier relationships).
2. Initial access: Exploitation of the unpatched vulnerability in the security product's exposed management interface, agent communication channel, or inline inspection component.
3. Tool deployment: Delivery of a customized, target-specific tool — likely staged in a writable directory such as /tmp, /var/tmp, C:\ProgramData, or the security product's own installation path to blend in.
4. Security neutralization: Tampering with, disabling, or blind-spotting the compromised security product to prevent detection of subsequent actions.
5. Objective execution: Movement toward wallet/signing infrastructure and exfiltration of funds — in crypto thefts this phase is often hours, not weeks. The "dwell time" that matters is the time to first transaction.

The lesson: in exchange and fintech environments, your detection strategy must assume the security stack itself is hostile terrain and instrument accordingly.

Detection & Response

This is a confirmed, actively exploited technical threat. The detections below target the behaviors described in the disclosure: exploitation of a security product, deployment of custom tooling, and tampering with defensive controls. They are deliberately tuned to the security stack itself, because that is where the attacker lived.

Sigma Rules

---
title: Security Product Service Stopped or Disabled via Command Line
id: 8f2c4a91-3d7e-4b5a-9c61-2e8f4a7b9d03
status: experimental
description: Detects attempts to stop, disable, or delete security product services using sc.exe, net.exe, or registry modification — a common post-exploitation behavior after compromising or bypassing endpoint security tooling, as seen in the Bitget third-party security product intrusion.
references:
  - https://thehackernews.com/2026/10/bitget-confirms-third-party-zero-day.html
  - https://attack.mitre.org/techniques/T1562/001/
author: Security Arsenal
date: 2026/10/15
tags:
  - attack.defense_evasion
  - attack.t1562.001
logsource:
  category: process_creation
  product: windows
detection:
  selection_tool:
    Image|endswith:
      - '\sc.exe'
      - '\net.exe'
      - '\net1.exe'
  selection_action:
    CommandLine|contains:
      - ' stop '
      - ' delete '
      - ' config '
      - ' disabled'
  selection_target:
    CommandLine|contains:
      - 'SentinelAgent'
      - 'CSFalconService'
      - 'MsSense'
      - 'SepMasterService'
      - 'cyserver'
      - 'edr'
      - 'Defender'
      - 'Sophos'
  condition: selection_tool and selection_action and selection_target
falsepositives:
  - Authorized security tooling maintenance windows executed by known admin accounts or software deployment systems
level: high
---
title: Security Product Process Spawning Unexpected Child Process
id: 2b7e9d14-6a3c-4f8b-b520-9d1e3c6a8f47
status: experimental
description: Detects shells, script interpreters, or LOLBins spawned as children of security product processes (EDR agents, AV engines, gateway daemons). Exploitation of a vulnerability in a security product frequently results in the product's own process executing attacker commands — the likely mechanism in the Bitget third-party zero-day intrusion.
references:
  - https://thehackernews.com/2026/10/bitget-confirms-third-party-zero-day.html
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/10/15
tags:
  - attack.execution
  - attack.t1059
  - attack.t1190
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\MsMpEng.exe'
      - '\SenseIR.exe'
      - '\CSFalconService.exe'
      - '\SentinelAgent.exe'
      - '\savservice.exe'
      - '\msmpsvc.exe'
      - '\ekrn.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
      - '\curl.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Vendor response actions and scripted remediation features that legitimately spawn shells (verify parent-child lineage against EDR console session logs)
level: critical
---
title: Executable Dropped in World-Writable or ProgramData Staging Directory by Non-Standard Parent
id: 5c1a8f36-9e2d-4b7a-a483-6f0d2b5e9c18
status: experimental
description: Detects creation of new executables in common staging directories (ProgramData, Temp, Public) consistent with deployment of a customized attacker tool, as recovered by SlowMist in the Bitget investigation.
references:
  - https://thehackernews.com/2026/10/bitget-confirms-third-party-zero-day.html
  - https://attack.mitre.org/techniques/T1074/
author: Security Arsenal
date: 2026/10/15
tags:
  - attack.persistence
  - attack.t1074.001
logsource:
  category: file_event
  product: windows
detection:
  selection_path:
    TargetFilename|contains:
      - '\ProgramData\'
      - '\Users\Public\'
      - '\AppData\Local\Temp\'
      - '\Windows\Temp\'
  selection_ext:
    TargetFilename|endswith:
      - '.exe'
      - '.dll'
      - '.sys'
      - '.scr'
  filter_installers:
    Image|endswith:
      - '\msiexec.exe'
      - '\setup.exe'
      - '\Teams.exe'
      - '\OneDriveSetup.exe'
  condition: selection_path and selection_ext and not filter_installers
falsepositives:
  - Legitimate software updaters and enterprise deployment tools writing to ProgramData; baseline known deployment agents before enabling at high fidelity
level: medium

KQL — Microsoft Sentinel / Defender

The first query hunts for security product processes spawning command interpreters or scripting engines — the exploitation signature. The second hunts for security agent service crashes, stops, or tampering events correlated with process creation from anomalous parent processes. Ingest Linux syslog/CEF from security appliances and gateways to extend coverage to non-Windows security products.

// Hunt 1: Security products spawning shells or LOLBins (exploitation indicator)
let SecurityProducts = dynamic(["MsMpEng.exe","CSFalconService.exe","SentinelAgent.exe","savservice.exe","ekrn.exe","SenseIR.exe","bdagent.exe"]);
let SuspiciousChildren = dynamic(["cmd.exe","powershell.exe","pwsh.exe","wscript.exe","cscript.exe","rundll32.exe","regsvr32.exe","certutil.exe","curl.exe","bitsadmin.exe","bash","sh"]);
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName in~ (SecurityProducts)
| where FileName in~ (SuspiciousChildren)
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
    FileName, ProcessCommandLine, AccountName, InitiatingProcessId, ProcessId, SHA256
| sort by TimeGenerated desc;

// Hunt 2: Security agent service stops, crashes, or restarts clustered with new process execution
SecurityEvent
| where TimeGenerated > ago(14d)
| where EventID == 7036
| where EventData has_any ("SentinelAgent","CSFalconService","MsSense","WinDefend","Sophos","SepMasterService")
| where EventData has_any ("stopped","disabled")
| extend ServiceAction = tostring(EventData)
| join kind=leftouter (
    DeviceProcessEvents
    | where TimeGenerated > ago(14d)
    | summarize RecentProcesses = make_list(strcat(FileName, " | ", ProcessCommandLine)) by DeviceName, bin(TimeGenerated, 1h)
) on DeviceName, $left.TimeGenerated >= $right.TimeGenerated
| project TimeGenerated, Computer, ServiceAction, RecentProcesses
| sort by TimeGenerated desc;

Velociraptor VQL

Use this hunt across server and workstation fleets (including Linux infrastructure common in exchange environments) to identify custom tooling staged in writable directories and security agents with unexpected outbound network connections — the two artifacts SlowMist's findings point toward.

-- Hunt: Recently dropped executables in staging directories and security agents with anomalous network connections
SELECT Pid, Name, Exe, CommandLine, Username, CreateTime,
       netstat().LocalIP AS LocalIP, netstat().LocalPort AS LocalPort,
       netstat().RemoteIP AS RemoteIP, netstat().RemotePort AS RemotePort,
       netstat().Status AS ConnStatus
FROM pslist()
WHERE (Exe =~ '(?i)(/tmp/|/var/tmp/|/dev/shm/|ProgramData|Users/Public|AppData/.*Temp)'
   AND Exe !~ '(?i)(msiexec|setup|installer|updater)')
   OR (Name =~ '(?i)(sentinel|falcon|sophos|defender|edr|av agent)'
   AND RemoteIP !~ '(?i)(10\\.|172\\.(1[6-9]|2[0-9]|3[0-1])\\.|192\\.168\\.|127\\.)')

For a file-focused sweep targeting the customized tool itself, pair with a glob hunt over staging paths:

-- Hunt: Executable files written to staging directories in the last 14 days
SELECT FullPath, Size, Mtime, Ctime,
       hash(path=FullPath).SHA256 AS SHA256
FROM glob(globs=['/tmp/**','/var/tmp/**','/dev/shm/**',
                 'C:/ProgramData/**/*.exe','C:/Users/Public/**/*.exe'])
WHERE NOT IsDir
  AND Mtime > now() - 1209600
  AND FullPath !~ '(?i)(chrome|firefox|teams|onedrive|zoom|slack)'
ORDER BY Mtime DESC

Remediation and Hardening Script

This Bash script inventories installed third-party security agents on Linux systems, verifies service integrity (running state, unexpected children), flags recent binaries in staging directories, and checks agent versions for follow-up against vendor advisories. Run it across your fleet via your configuration management tooling.

#!/bin/bash
# Security Stack Integrity Audit — post-Bitget third-party zero-day response
# Run as root. Output to /var/log/security-stack-audit-<hostname>.log

LOG="/var/log/security-stack-audit-$(hostname)-$(date +%Y%m%d).log"
echo "=== Security Stack Audit: $(date) ===" | tee -a "$LOG"

# 1. Inventory installed security agents and versions
echo "[+] Installed security agents:" | tee -a "$LOG"
rpm -qa 2>/dev/null | grep -iE 'sentinel|falcon|crowdstrike|sophos|defender|qualys|tanium|carbonblack|cylance' | tee -a "$LOG"
dpkg -l 2>/dev/null | grep -iE 'sentinel|falcon|crowdstrike|sophos|defender|qualys|tanium|carbonblack|cylance' | tee -a "$LOG"

# 2. Verify security services are actually running (detect tampering/stops)
echo "[+] Security service state:" | tee -a "$LOG"
for svc in falcon-sensor SentinelAgent sophos-spl qualys-cloud-agent; do
    systemctl is-active "$svc" 2>/dev/null | sed "s/^/  $svc: /" | tee -a "$LOG"
done

# 3. Flag security agent processes spawning shells (exploitation indicator)
echo "[+] Security agents with shell/script children:" | tee -a "$LOG"
ps -eo pid,ppid,comm,args | awk 'NR==FNR{a[$1]=$3; next} ($2 in a) && a[$2] ~ /falcon|sentinel|sophos|sav|bdagent/ && $3 ~ /bash|sh|python|perl|curl|wget/ {print}' /dev/stdin <(ps -eo pid,comm) | tee -a "$LOG"
ps aux | grep -iE 'falcon|sentinel|sophos' | grep -v grep | tee -a "$LOG"

# 4. Sweep staging directories for recent executables (custom tool artifacts)
echo "[+] Executables in /tmp, /var/tmp, /dev/shm modified in last 14 days:" | tee -a "$LOG"
find /tmp /var/tmp /dev/shm -type f -mtime -14 \( -perm -u+x -o -name '*.elf' -o -name '*.so' \) -exec ls -la {} \; 2>/dev/null | tee -a "$LOG"

# 5. Check for unexpected outbound connections from security agent processes
echo "[+] Security agent outbound connections:" | tee -a "$LOG"
ss -tupn 2>/dev/null | grep -iE 'falcon|sentinel|sophos|sav' | grep -vE '10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.|192\.168\.|127\.' | tee -a "$LOG"

# 6. Check for pending security updates
echo "[+] Pending security updates:" | tee -a "$LOG"
(apt-get -s upgrade 2>/dev/null | grep -i '^Inst' | grep -i security) || (yum updateinfo list security 2>/dev/null) | tee -a "$LOG"

echo "=== Audit complete. Review $LOG and cross-check agent versions against current vendor advisories. ===" | tee -a "$LOG"

For Windows fleets, the equivalent verification via PowerShell:

# Security Stack Integrity Audit - Windows
# Run elevated. Review output before remediating.

# 1. Verify EDR/AV services are running and not tampered
Get-Service | Where-Object { $_.DisplayName -match 'Defender|Sentinel|CrowdStrike|Sophos|Carbon Black' } |
  Select-Object Name, DisplayName, Status, StartType | Format-Table -AutoSize

# 2. Flag security product processes with suspicious children (last 14 days)
$secProcs = 'MsMpEng|CSFalconService|SentinelAgent|savservice'
Get-CimInstance Win32_Process | Where-Object {
  $p = Get-CimInstance Win32_Process -Filter "ProcessId=$($_.ParentProcessId)" -ErrorAction SilentlyContinue
  $p.Name -match $secProcs -and $_.Name -match 'cmd|powershell|wscript|rundll32|certutil'
} | Select-Object ProcessId, Name, CommandLine, CreationDate

# 3. Sweep staging directories for recent executables (custom tool artifacts)
$cutoff = (Get-Date).AddDays(-14)
Get-ChildItem 'C:\ProgramData','C:\Users\Public',"$env:TEMP" -Recurse -Include *.exe,*.dll,*.sys -ErrorAction SilentlyContinue |
  Where-Object { $_.LastWriteTime -gt $cutoff } |
  Select-Object FullName, LastWriteTime, Length,
    @{N='SHA256';E={(Get-FileHash $_.FullName -Algorithm SHA256 -ErrorAction SilentlyContinue).Hash}}

# 4. Check Microsoft Defender tamper protection state
Get-MpComputerStatus | Select-Object IsTamperProtected, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated

Remediation: What To Do Right Now

Because Bitget and SlowMist have not yet named the specific third-party product (likely pending coordinated disclosure), your remediation strategy must be architectural, not advisory-chasing. When the vendor advisory drops, your patch window will be measured in hours — prepare now.

Immediate (24–48 hours)

1. Inventory your entire security stack as attack surface. Produce a current list of every third-party security product, agent, appliance, and plugin in your environment — EDR, email gateway, WAF, VPN, PAM, monitoring agents — with exact version numbers and exposed interfaces (management consoles, API endpoints, agent listening ports).
2. Audit management plane exposure. Security product consoles must not be internet-reachable. Verify and firewall accordingly. Shodan-exposed EDR consoles and gateway admin panels are routinely scanned by the same actors targeting exchanges.
3. Deploy the detections above. Instrument the security stack itself: service stop/start telemetry, parent-child process lineage for security agents, and network connections from security product processes. Ship these logs to a SIEM that the security products themselves cannot suppress — an out-of-band collector or a separate monitoring tenant.
4. Hunt for staging artifacts. Sweep /tmp, /var/tmp, /dev/shm, C:\ProgramData, and C:\Users\Public for executables modified in the last 30 days. The recovered custom tool in the Bitget case was almost certainly staged somewhere writable.
5. Enable tamper protection everywhere. Verify Defender tamper protection, EDR self-protection, and agent uninstall passwords are enforced across the fleet, and alert on any change to those states.

Short-Term (1–2 weeks)

6. Establish a security-product patch SLA. Treat security tooling patches with the same urgency as internet-facing CVEs — a 72-hour maximum for critical flaws in EDR, gateways, and VPNs. The Bitget incident exists because an unpatched window stayed open.
7. Subscribe to every security vendor's advisory feed. Add vendor PSIRT mailing lists and RSS feeds for each product in your stack to your vulnerability management intake. Monitor CISA KEV daily — security product flaws exploited in the wild are added rapidly, and KEV inclusion carries a federal remediation deadline that is a useful forcing function for private-sector SLAs.
8. Segment the security management plane. Place security consoles, update servers, and agent brokers in a dedicated management VLAN with strict egress rules. A compromised agent or console should not have a network path to wallet infrastructure, domain controllers, or signing systems.
9. For crypto and fintech specifically: isolate wallet signing infrastructure behind separate trust boundaries with out-of-band transaction approval. Assume host compromise; make key material unusable from any single compromised system (MPC, HSM-backed, multi-party approval).

Strategic

10. Threat-model your defenders. Add "compromise of our own security tooling" as an explicit scenario in tabletop exercises and purple team engagements. Test whether your SOC would detect an EDR agent spawning cmd.exe or a gateway daemon making outbound connections.
11. Contractual due diligence. Require vendors to disclose their own patch cadence, secure development practices, and breach notification timelines. Third-party security products are supply chain — assess them like it.
12. Out-of-band detection. Deploy at least one detection layer independent of your primary security vendor (e.g., network detection and response, canary tokens, or a second-vendor sensor on critical segments) so a single-product compromise doesn't blind you.

The Bottom Line

The Bitget theft is the most expensive proof yet of a truth practitioners have been repeating for years: security products are software, software has vulnerabilities, and a vulnerability in your security stack is worse than a vulnerability anywhere else — because it grants privilege, position, and silence simultaneously. SlowMist's recovery of a customized attacker tool tells us this was a prepared, targeted operation. The actors hitting exchanges and financial infrastructure in 2026 are doing their homework on your defensive stack. Do yours.

Audit your security tooling today. Patch it like it's internet-facing — because from the attacker's perspective, it is.

Related Resources

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