CTI Daily Brief — 2026-05-18

THORChain GG20 Threshold Signature Scheme vault drain — ~$11M across nine chains; Switzerland-based protocol

On 2026-05-15 a malicious validator node drained approximately $11M in protocol-owned funds from THORChain, a Switzerland-based decentralised cross-chain liquidity protocol founded in 2018, across Bitcoin, Ethereum, BNB Smart Chain, Base, Avalanche, Dogecoin, Litecoin, Bitcoin Cash, and XRP (The Record, 2026-05-15; TRM Labs, 2026-05-15). The leading technical hypothesis — reported by Chainalysis, PeckShield and Cyvers via CryptoTimes's post-mortem synthesis on 2026-05-17 — is a GG20 Threshold Signature Scheme (TSS) implementation flaw: a node identified as thor16ucjv3v695mq283me7esh0wdhajjalengcn84q joined the active validator set days before the attack, gradually leaked vault key shards during keygen and signing rounds, reconstructed sufficient key material offline, and then forged outbound vault signatures without triggering the protocol's quorum checks. CryptoTimes records verbatim: "the operator (or a compromised machine acting as the operator) exploited a vulnerability in the GG20 Threshold Signature Scheme implementation. Rather than a single dramatic key compromise, the attack appears to have involved the gradual leakage of vault key material during keygen or signing rounds — the kind of malformed-proof exploitation that the TSSHOCK class of CVEs first put on the industry's radar a few years ago." Chainalysis shared an on-chain analysis thread on 2026-05-16 linking attacker-controlled wallets to weeks of preparatory infrastructure staging through Monero and Hyperliquid before the vault drain. TRM Labs traced the proceeds to a two-address cluster within hours but has not attributed the exploit to any specific actor as of disclosure; historical THORChain laundering activity has been dominated by North Korean operators (Lazarus Group, including the $1.5B Bybit and ~$300M KelpDAO thefts per TRM Labs), but no Lazarus attribution is confirmed for this event. The Record reports user balances were not directly drained. Why it matters to us: the relevance to a Swiss / EU public-sector SOC is the technique class, not the cryptocurrency context. Any organisation operating MPC-custody, threshold-signing, or cross-chain bridge validator infrastructure — including FINMA-supervised digital-asset custodians, EU MiCA-regulated DeFi platforms, and any internal HSM-replacement projects that have moved to MPC-TSS — should audit node-admission controls, keygen/signing-round integrity, and whether newly-joined nodes can participate in signing quorums before completing a full security review. The TSSHOCK vulnerability class — CVE-2023-33241 (Fireblocks GG18/GG20 Paillier-ZK-proof flaw) and related GG20/ECDSA-MPC research — showed that malformed or missing zero-knowledge proofs during GG18/GG20 keygen can leak private-key shards across multiple rounds; the THORChain exploit is the second large-scale production demonstration of that theoretical class.

CVE-2026-42897 Exchange OWA — EM Service auto-mitigation depends on outbound connectivity to officemitigations.microsoft.com

UPDATE (originally covered 2026-05-15 / deep-dive 2026-05-16): The Microsoft Exchange Team Blog post addressing CVE-2026-42897 was last modified 2026-05-17 to clarify an operational dependency that defenders must verify on every Exchange Mailbox host: the Exchange Emergency Mitigation Service (EM Service / EEMS) — which auto-applies the URL-Rewrite mitigation labelled M2.1.x — only delivers that mitigation when it can reach officemitigations.microsoft.com over outbound HTTPS. Segmented on-premises Exchange 2016 / 2019 / Subscription-Edition deployments that block direct outbound HTTPS from the Mailbox role will therefore not have received the automatic mitigation and remain exposed to the actively-exploited OWA stored-XSS chain.

The CVE remains CISA KEV-listed (added 2026-05-15) with no permanent cumulative-update fix as of 2026-05-18; Microsoft states verbatim "We are working on developing and testing a more permanent fix which we will provide when it meets our quality standards." Exchange Online is unaffected. Operational verification per server: Get-ExchangeDiagnosticInfo -Server <server> -Process EdgeTransport -Component EmergencyMitigation returns Status: Active and rule M2.1.x applied; manual application on hosts that cannot reach the mitigation service: .\EOMT.ps1 -CVE "CVE-2026-42897" from an elevated Exchange Management Shell, or apply the documented URL Rewrite rule by hand.

CVE-2026-42945 NGINX Rift — in-the-wild exploitation confirmed by VulnCheck honeypots

UPDATE (originally covered 2026-W21 weekly): VulnCheck honeypot telemetry confirmed active exploitation of CVE-2026-42945 on 2026-05-17, promoting the 18-year-old ngx_http_rewrite_module heap buffer overflow from PoC-public status (where it sat last week) to actively-exploited. The flaw is reachable by an unauthenticated remote attacker via a single crafted HTTP request to any NGINX instance running a rewrite-rule configuration that uses unnamed PCRE captures ($1, $2); successful exploitation crashes the worker process (DoS reliable on ASLR-enabled hosts) and reaches RCE on hosts where ASLR is disabled.

Affected per F5 PSIRT advisory K000161019: NGINX Open Source 0.6.27 through 1.30.0 (every release since 2008) and NGINX Plus R32 through R36, plus F5 NGINX Instance Manager, NGINX Ingress Controller, NGINX Gateway Fabric, NGINX App Protect WAF, F5 WAF for NGINX, and NGINX App Protect DoS. Patches: NGINX Open Source 1.30.1 / 1.31.0; NGINX Plus R32 P6, R36 P4. Interim mitigation if immediate upgrade is not possible: convert unnamed PCRE captures in all rewrite directives to named captures ((?P<name>...) syntax). Detection-engineering anchors that follow from the flaw class (heap-overflow worker crash under specific rewrite-rule configurations) are NGINX worker-process crash events (SIGSEGV / SIGABRT and immediate respawn) in syslog / journald, correlated with inbound HTTP requests carrying unusually long or deeply-nested rewrite-rule input strings from the same source; defenders should validate these against their own rewrite-rule configuration before depending on them.

CVE-2026-0300 PAN-OS Captive Portal — revised fix-release timelines for 10.2.13-h21 and 10.2.16-h7; wave-2 target remains 2026-05-28

UPDATE (originally covered 2026-05-07 deep dive): The Palo Alto Networks PSIRT advisory for CVE-2026-0300 was revised on 2026-05-16 to update the per-build fix-release schedule: PAN-OS 10.2.13-h21 was retimed on 2026-05-16, 10.2.16-h7 on 2026-05-14. Both are commonly deployed LTS branches in large enterprise and government estates; PA-Series and VM-Series devices on those two specific builds remain mitigation-only.

The wave-2 patch target for the remaining outstanding builds remains 2026-05-28. No new exploitation evidence accompanied the revision; the actively-exploited posture (unauthenticated heap overflow in the User-ID Authentication Portal / Captive Portal service, CVSS 9.3, pre-auth root RCE) reported in prior briefs continues. Defender action: verify each PA / VM appliance's installed PAN-OS build against the advisory's per-version patch matrix; if the installed build is 10.2.13-h21 or 10.2.16-h7, confirm the Captive Portal / User-ID Authentication Portal mitigation (disable the feature if unused, or apply the published Threat Prevention rule) remains active until the wave-2 fix lands.

Tycoon2FA after the March 2026 takedown — OAuth Device Authorization Grant abuse on Microsoft 365

Background. Tycoon2FA is one of the established Microsoft 365 Phishing-as-a-Service (PhaaS) kits, previously documented as a classic adversary-in-the-middle (AiTM) credential-relay kit (Sekoia's reference analysis catalogued earlier versions of the kit). eSentire's Threat Response Unit documented a late-April 2026 campaign in which the kit's operators have moved away from credential-relay AiTM and are now abusing the legitimate OAuth 2.0 Device Authorization Grant flow as their post-MFA token-theft primitive (eSentire TRU, 2026-05-12; BleepingComputer, 2026-05-17). The substantive defender consequence is that the new chain runs against Microsoft's own authentication endpoints rather than against a credential-relay proxy the defender could block at the infrastructure layer; the abuse is structurally indistinguishable from a legitimate device-code sign-in until the resulting token is used.

Attack chain. A phishing email directs the victim through a four-layer browser chain documented by eSentire: a Trustifi click-tracking redirect (legitimate-email-marketing infrastructure, abused for reputation laundering) hands off to a Cloudflare Workers throwaway subdomain whose stage performs anti-analysis fingerprinting, AES-GCM-encrypted JavaScript decrypts the next stage only when the browser fingerprint clears, and finally the victim lands on a fake Microsoft CAPTCHA / "Check Domain" page that bridges into the OAuth device-code lure. eSentire records the underlying hosting ASN rotated to AS45102 (Alibaba Cloud) from 2026-04-10 onward, replacing previously documented ASNs. The terminal step is the technique pivot: instead of relaying credentials through an AiTM proxy, the phishing site displays a Microsoft-branded prompt instructing the victim to "complete sign-in by visiting microsoft.com/devicelogin and entering this code: AB12-CDEF". The code is a real device code that the attacker pre-generated by calling the OAuth Device Authorization Grant endpoint (/oauth2/v2.0/devicecode) on the victim's tenant, presenting itself as the Microsoft Authentication Broker client (AppId 29d9ed98-a469-4536-ade2-f981bc1d605e) — a first-party Microsoft client whose presence does not trip standard "unknown OAuth app" alerts in Entra ID. When the victim completes the device-code login in their browser they are authenticating to genuine Microsoft endpoints, MFA fires and succeeds against the victim's own MFA method (push, OTP, SMS) — and the resulting access and refresh tokens are issued to the attacker's polling device, not the victim. Entra ID sign-in logs record this as AuthenticationProtocol = deviceCode originating from an unfamiliar IP, but the actual authentication is logged as successful with valid MFA, masking the abuse.

ATT&CK mapping. T1566.002 Phishing: Spearphishing Link → T1528 Steal Application Access Token (the device-code flow itself) → T1550.001 Use Alternate Authentication Material: Application Access Token → T1078.004 Valid Accounts: Cloud Accounts (sustained post-MFA access using the issued tokens against Exchange Online, SharePoint, OneDrive, Teams, and Graph API). MFA bypass is structural here — Tycoon2FA does not break MFA; it sidesteps it by binding the MFA-validated session to an attacker-owned device through the legitimate OAuth flow. Every MFA method except FIDO2 / WebAuthn with phishing-resistant attestation is vulnerable to this attack class because the victim approves an MFA prompt on a flow the kit chose, not the flow the victim believes they are completing.

Hunt / detection concepts. Per eSentire's TRU analysis: query Entra ID sign-in logs for AuthenticationProtocol = "deviceCode" paired with ClientAppUsed = "Microsoft Authentication Broker" from IPs the user has never authenticated from previously; alert on any device-code authentication from foreign ASNs against high-privilege users (Global Admins, Privileged Role Admins, Compliance Admins) regardless of MFA outcome; correlate device-code sign-ins with Entra audit-log entries showing immediate token-refresh activity against Exchange Online or SharePoint endpoints (Add OAuth2PermissionGrant); on the email layer hunt for inbound mail containing the literal string microsoft.com/devicelogin paired with a device-code-shaped substring (eight alphanumerics with a hyphen at the midpoint) in the body — legitimate Microsoft messaging almost never instructs an end user to enter such a code in response to an email. Kit-fingerprint detection (useful when investigating a confirmed campaign): the Tycoon2FA browser stage retains the hardcoded CryptoJS AES-CBC key 1234567890123456 first documented in the kit's 2024 build, and the fake CAPTCHA layer still embeds the same Cloudflare-anti-bot bypass JavaScript across the rebuilt infrastructure.

Hardening. Entra Conditional Access policy to block OAuth Device Code flow as an authentication transport for users who do not need it — the policy is Conditional Access > New policy > Conditions > Authentication flows > Device code flow > Block; Microsoft recommends this as a tenant-wide default in modern deployments because the device-code flow is only legitimately needed for input-constrained devices (smart TVs, IoT, CLI tools) and almost never for desktop or browser users. Where a wholesale block is operationally infeasible, scope the block to all licensed user accounts and exempt only the named service principals that require it. Enable Continuous Access Evaluation (CAE) so that anomaly-driven sign-in revocation can cut an attacker's session within minutes rather than hours. Migrate high-privilege users to FIDO2 / WebAuthn with phishing-resistant attestation as their only permitted MFA method — the device-code flow can still be initiated, but the attacker cannot complete it because the FIDO2 origin-binding fails on a non-matching browser session. Awareness messaging should make explicit that Microsoft never sends device codes via email and that any incoming message asking the recipient to enter a code at microsoft.com/devicelogin is fraudulent regardless of the apparent sender.