# Active Exploitation of BTCPay Server Instances Draining Bitcoin Hot Wallets (Versions Older Than 2.4.2)

> On 2026-11-01 BTCPay Server told operators to shut down after reports that hot wallets on self-hosted instances were being swept by attackers who had obtained administrator-level access. Affected deployments ran releases older than 2.4.2; the entry vector is not yet confirmed and the investigation is ongoing.

- **Published:** 2026-11-02T04:16:29Z
- **Last reviewed:** 2026-11-02T04:16:29Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-5028
- **Card image:** https://intel.threadlinqs.com/og/threat/TL-2026-5028.png
- **ID:** TL-2026-5028
- **Severity:** HIGH
- **Category:** VULNERABILITY
- **Status:** ACTIVE
- **Detections:** 9 (1 shown free below) · **IOCs:** 8

## Description

On the evening of 2026-11-01 (about 22:25 UTC) the official BTCPay Server account announced: "We are receiving reports of hot wallets on BTCPay Servers being swept by unauthorized attackers. If you're running an instance, please shut it down (./btcpay-down.sh) until we complete the investigation." Operators were told to keep instances offline and not restart without an official all-clear.

Preliminary findings, relayed by founder Nicolas Dorier and reported by Bitcoin.com and TokenPost, indicate that affected deployments were running software predating 2.4.2 and that an attacker had logged in as an administrator. How administrator access was obtained has not been determined: stolen credentials, a software vulnerability, or another vector all remain open. Public BTCPay servers running 2.4.7 (released 2026-10-29) were reportedly not attacked. BTCPay has not disclosed the number of affected servers or the amount of bitcoin taken, and no network or file IOCs have been published.

Context that defenders should weigh, without assuming causation: in August 2026 BTCPay Server shipped 2.4.2 (2026-08-07) to fix an issue that was actively exploited to steal LND Lightning macaroon credentials, draining Lightning nodes of Foundation and Citadel21. One technical write-up (pasqualepillitteri.it) attributes that earlier flaw to the Greenfield API Basic Authentication handler checking only for FIDO2 credentials and therefore bypassing TOTP-only two-factor protection, allowing retrieval of admin.macaroon with just an email and password; other outlets describe it more generally as unauthenticated macaroon exposure. That earlier incident affected Lightning (LND) nodes, while the November reports concern on-chain hot wallets. BTCPay has not said whether the November thefts are linked to the August flaw or to the issues fixed in 2.4.7. On 2026-10-29 BTCPay released emergency 2.4.7, reported by Bitcoin.com as fixing 85 vulnerabilities (1 critical, 13 high, 52 medium, 19 low) found via an Anthropic security-scanning initiative; it is not established that these relate to the sweeps.

Risk: any BTCPay instance older than 2.4.2 holding funds in a BTCPay-generated hot wallet should be treated as potentially compromised. Updating alone is not considered sufficient if an instance was already compromised: rotate administrator credentials and API keys, review admin users and logins, and move funds. Classification is category VULNERABILITY, severity HIGH (analyst-assigned from confirmed in-the-wild fund theft; no CVE or CVSS exists).

## MITRE ATT&CK

- T1078 Valid Accounts
- T1190 Exploit Public-Facing Application
- T1552.001 Unsecured Credentials: Credentials In Files
- T1550.001 Use Alternate Authentication Material: Application Access Token
- T1657 Financial Theft

## Free detection (Splunk SPL, Microsoft KQL, Sigma)

**BTCPay Server Greenfield API Credential Guessing Followed by Success (TL-2026-5028)** (`TL-2026-5028-SPL-001`)

Detects an external client that fails authentication against the BTCPay Server Greenfield API (/api/v1/*) at least 5 times and then succeeds. TL-2026-5028 reports attackers logging in as BTCPay administrator on pre-2.4.2 instances to sweep hot wallets; the entry vector is unconfirmed, and this behaviour covers credential-based access to the administrative API. Requires reverse-proxy access logs.

- **Languages:** Splunk SPL, Microsoft KQL, Sigma
- **ATT&CK:** T1190, T1078
- **Data sources:** nginx_access_logs (index=web sourcetype=access_combined), azure_application_gateway_access_logs
- **Severity:** high
- **Confidence:** high

### Splunk SPL

```spl
index=web sourcetype=access_combined earliest=-24h uri_path="/api/v1/*"
| where NOT (cidrmatch("10.0.0.0/8",clientip) OR cidrmatch("172.16.0.0/12",clientip) OR cidrmatch("192.168.0.0/16",clientip))
| eval outcome=case(status=401 OR status=403,"fail", status>=200 AND status<300,"success", true(),"other")
| stats count AS requests, sum(eval(if(outcome="fail",1,0))) AS failures, sum(eval(if(outcome="success",1,0))) AS successes, values(uri_path) AS paths, min(_time) AS first_seen BY clientip
| where failures>=5 AND successes>=1
| convert ctime(first_seen)
```

### Microsoft KQL

```kql
AzureDiagnostics
| where TimeGenerated > ago(24h) and Category == "ApplicationGatewayAccessLog"
| where not(ipv4_is_private(clientIP_s))
| where requestUri_s startswith "/api/v1/"
| summarize Requests=count(), Failures=countif(httpStatus_d in (401, 403)), Successes=countif(httpStatus_d between (200 .. 299)), Paths=make_set(requestUri_s, 20), FirstSeen=min(TimeGenerated) by clientIP_s
| where Failures >= 5 and Successes >= 1
```

### Sigma

```yaml
title: BTCPay Server Greenfield API Authentication Failure From External Source
name: btcpay_greenfield_auth_failure
id: 5c0e7a11-5028-4d0a-9b21-3f6a1c0d5001
status: experimental
description: Base rule for TL-2026-5028. Matches failed authentication (401/403) against the BTCPay Server Greenfield API (/api/v1/) from external sources. The paired correlation rule fires on 5 or more failures from one client within 10 minutes. Failure-then-success is evaluated in the SPL and KQL forms.
references:
  - https://news.bitcoin.com/security/bitcoin-payment-processor-btcpay-hit-by-hot-wallet-theft-reports/
author: AII-Detector — ThreadLinqs Intelligence
date: 2026-11-02
tags:
  - attack.initial_access
  - attack.t1190
  - attack.t1078
logsource:
  category: webserver
detection:
  selection:
    cs-uri-stem|startswith: '/api/v1/'
    sc-status:
      - 401
      - 403
  filter_internal:
    c-ip|cidr:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
  condition: selection and not filter_internal
falsepositives:
  - Misconfigured integrations or monitoring probes using an expired API key
  - Merchant plugins retrying with a rotated credential
level: medium
---
title: BTCPay Server Greenfield API Authentication Failure Burst
id: 5c0e7a11-5028-4d0a-9b21-3f6a1c0d5002
status: experimental
description: Five or more failed Greenfield API authentications from one client within 10 minutes (TL-2026-5028).
author: AII-Detector — ThreadLinqs Intelligence
date: 2026-11-02
correlation:
  type: event_count
  rules:
    - btcpay_greenfield_auth_failure
  group-by:
    - c-ip
  timespan: 10m
  condition:
    gte: 5
level: medium

```

**Known false positives:**

- Merchant integration with a rotated or expired API key that retries before being fixed
- Authorized penetration test or vulnerability scan against the BTCPay host

**Tuning notes:** Replace the RFC1918 exclusions with your corporate and VPN egress ranges; if BTCPay is behind a CDN or proxy, use the X-Forwarded-For field instead of clientip. Adjust the failure threshold (5) per baseline and keep the 24h window equal to the alert schedule. Map index/sourcetype to your proxy log pipeline.

### 8 more detection rules (Splunk SPL, Microsoft KQL, Sigma), unlock with TL Creds

- BTCPay Greenfield API Payment-Method Config and Macaroon Exposure (TL-2026-5028) (locked: unlock with TL Creds)
- BTCPay Unauthorized Admin User or API Key Creation via Greenfield API (TL-2026-5028) (locked: unlock with TL Creds)
- LND/Bitcoin CLI Wallet Sweep Commands on BTCPay Host (TL-2026-5028) (locked: unlock with TL Creds)
- BTCPay Greenfield API Admin Enumeration from External IP (TL-2026-5028) (locked: unlock with TL Creds)
- Docker Exec/Copy of LND Macaroon from BTCPay Containers (TL-2026-5028) (locked: unlock with TL Creds)
- LND Channel Force-Close Commands on BTCPay Host (TL-2026-5028) (locked: unlock with TL Creds)
- LND Macaroon File Access by Copy, Encode or Transfer Tools (TL-2026-5028) (locked: unlock with TL Creds)
- BTCPay On-Chain Hot Wallet Spend via API from External Source (TL-2026-5028) (locked: unlock with TL Creds)

Sign up free to unlock the detection rules: https://threadlinqs.com/?modal=signup

## Sources

- [Hackers Drain Bitcoin Hot Wallets on BTCPay Servers, Users Urged to Shut Down Immediately](https://cybersecuritynews.com/btcpay-server-warns/)
- [Bitcoin Payment Processor Btcpay Hit by Hot Wallet Theft Reports](https://news.bitcoin.com/security/bitcoin-payment-processor-btcpay-hit-by-hot-wallet-theft-reports/)
- [BTCPay Founder Says Theft Reports May Involve Older Versions](https://www.tokenpost.com/news/technology/46072)
- [BTCPay Server tells operators to shut down after reports of hot wallets being drained](https://investinglive.com/cryptocurrency/btcpay-server-tells-operators-to-shut-down-after-reports-of-hot-wallets-being-drained/)
- [Soft ACK: FORENSIC ACTIVE - BTCPay Server hot-wallet sweeps / emergency shutdown (1-2 Nov 2026)](https://github.com/0xsyung/0xterm-app/issues/282)
- [BTCPay Server 2.4.2: the Flaw Draining Lightning Nodes](https://pasqualepillitteri.it/en/news/10299/btcpay-server-vulnerability-lightning-nodes)
- [Another Bitcoin infrastructure exploit hits, this time draining merchant Lightning nodes](https://coindesk.com/tech/2026/08/08/another-bitcoin-infrastructure-exploit-hits-this-time-draining-merchant-lightning-nodes)
- [BTCPay restricts remote Lightning access after attackers steal funds](https://cointelegraph.com/news/btcpay-restricts-remote-lightning-access-after-attackers-steal-funds)
- [BTCPay Server supporters offer up to 3 BTC for recovery bounty after critical exploit](https://theblock.co/news/ecosystems/2026-08-10-btcpay-server-supporters-offer-3-btc-recovery-bounty-critical-exploit-411353)

## Full data

The other 8 detection rules (Splunk SPL / Microsoft KQL / Sigma) unlock with TL Creds; a free account includes daily creds: https://threadlinqs.com/?modal=signup
Indicator values unlock with TL Creds, at a lower price on Red and Purple; AI agents can query rules and IOCs through the Threadlinqs MCP server (Purple): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-5028