CTI Daily Brief — 2026-05-18

• Microsoft Exchange Server CVE-2026-42897 (OWA stored XSS, actively exploited, CISA KEV) — Exchange Team Blog update confirms the EM Service auto-mitigation requires outbound HTTPS connectivity from the Exchange host to officemitigations.microsoft.com. Segmented or air-gapped Exchange 2016 / 2019 / SE environments that block this egress path will not have received the automatic URL-Rewrite mitigation and remain exposed; no permanent patch is available yet (Microsoft Exchange Team Blog, 2026-05-17; Microsoft MSRC).
• NGINX Rift CVE-2026-42945 — VulnCheck honeypot telemetry confirms in-the-wild exploitation as of 2026-05-17. The 18-year-old heap overflow in ngx_http_rewrite_module (versions 0.6.27 through 1.30.0) is now actively probed; patches are NGINX Open Source 1.30.1 / 1.31.0 and NGINX Plus R32 P6 / R36 P4 (The Hacker News, 2026-05-17; Security Affairs, 2026-05-14).
• THORChain — Switzerland-based cross-chain liquidity protocol — drained of ~$11M across nine blockchains via a suspected GG20 Threshold-Signature-Scheme implementation flaw. A malicious newly-churned validator node is reported to have gradually leaked vault key shards over multiple keygen/signing rounds before forging outbound signatures; The Record reports user funds were unaffected and only protocol-owned assets were impacted (The Record, 2026-05-15; TRM Labs, 2026-05-15).
• Tycoon2FA PhaaS pivots from credential-relay AiTM to OAuth 2.0 Device Authorization Grant abuse against Microsoft 365. Victims paste an attacker-supplied device code into the legitimate microsoft.com/devicelogin endpoint; MFA succeeds on the real Microsoft endpoint and tokens are issued to the attacker's registered device. eSentire documented the campaign with a four-layer browser chain ending in a fake Microsoft CAPTCHA (BleepingComputer, 2026-05-17; eSentire TRU, 2026-05-12).

Immediate Action — Verify Exchange Emergency Mitigation Service health and officemitigations.microsoft.com connectivity. CVE-2026-42897 is an actively-exploited OWA stored-XSS with no permanent patch; the EM Service auto-applies the URL-Rewrite mitigation M2.1.x only if outbound HTTPS to officemitigations.microsoft.com is reachable from each Exchange Mailbox server. Segmented or restricted-egress on-premises Exchange 2016 / 2019 / SE estates may be silently unprotected. Right now: run Get-ExchangeDiagnosticInfo -Server <server> -Process EdgeTransport -Component EmergencyMitigation on every Mailbox role, confirm Status Active and rule M2.1.x applied; on segmented servers run .\EOMT.ps1 -CVE "CVE-2026-42897" manually from an elevated Exchange Management Shell.

No new in-window CVE clears the § 2 inclusion gates this run — the three actively-exploited or newly-patched items in scope (CVE-2026-42897 Exchange OWA, CVE-2026-42945 NGINX Rift, CVE-2026-0300 PAN-OS) all carry material in-window deltas that belong in § 4 Updates rather than as fresh § 2 entries. Section intentionally left empty.

No new research with operational defender impact published inside the 36-hour recency window this run — Sunday-into-Monday is research-light. Three substantive pieces (DFIR Report on EtherRAT + TukTuk → Gentleman ransomware, 2026-05-11; Microsoft IR on a 123-day MSP-mediated intrusion via HPE Operations Manager, 2026-05-12; Unit 42 on AD CS ESC1 + shadow-credential exploitation by Fighting Ursa, 2026-05-11) were surfaced by S3 but all fall outside the strict window and outside prior coverage; they are flagged in § 7 as candidates for the weekly summary rather than padded into today's brief. Section intentionally left empty.

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.

• Verify Exchange Emergency Mitigation Service health on every on-premises Mailbox role. Run Get-ExchangeDiagnosticInfo -Server <server> -Process EdgeTransport -Component EmergencyMitigation against each Exchange 2016 / 2019 / SE host; confirm Status: Active and rule M2.1.x is applied. On segmented hosts that block outbound HTTPS to officemitigations.microsoft.com, manually apply via .\EOMT.ps1 -CVE "CVE-2026-42897" from an elevated Exchange Management Shell. No permanent patch yet; CISA KEV-listed and actively exploited. See § 4 update.

• Patch NGINX 1.30.0 → 1.30.1 / 1.31.0 (open source) or NGINX Plus → R32 P6 / R36 P4 immediately on any internet-exposed instance. VulnCheck honeypot telemetry confirmed in-the-wild exploitation of CVE-2026-42945 ("NGINX Rift") on 2026-05-17. Where same-day upgrade is not feasible, audit nginx.conf and included *.conf rewrite rules for unnamed PCRE captures ($1, $2) and convert to named captures as an interim mitigation per the F5 advisory. See § 4 update.

• Block OAuth Device Code flow tenant-wide in Entra ID Conditional Access where it is not operationally required. Path: Conditional Access → New policy → Conditions → Authentication flows → Device code flow → Block. Scope to all user accounts and exempt only the named service principals (smart-TV, IoT, CLI) that demonstrably need it. Where a wholesale block is infeasible, restrict the device-code flow to compliant devices and named-location IPs. Monitor Entra ID sign-in logs for AuthenticationProtocol = "deviceCode" from unfamiliar IPs against high-privilege users — see § 5 deep dive.

• Audit PAN-OS build version against the revised CVE-2026-0300 fix-release timeline. Inventory PA-Series and VM-Series appliances; if any device runs 10.2.13-h21 or 10.2.16-h7, confirm Captive Portal / User-ID Authentication Portal mitigation remains active and track the wave-2 patch target (2026-05-28). See § 4 update.