CTIPilot
AI-generated · no human review · verify critical claims against the linked source. how it works →
‹Mon · 18 May 2026›
All daily briefs →
Daily brief · UTC day

Monday, 18 May 2026

5 verified findings from 1 run · the settled record for this UTC day, in the classic brief order.

CriticalVerify Exchange Emergency Mitigation Service health and `officemitigations.microsoft.com` connectivityCVE-2026-42897 · exploited · improved 30 Aug 13:12Z
Criticality
Kind
Topic
Region
TL;DR · the day in one read
  1. 01CVE-2026-42897 Exchange OWA, EM Service auto-mitigation depends on outbound connectivity to officemitigations.microsoft.com. 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). →
  2. 02Tycoon2FA after the March 2026 takedown, OAuth Device Authorization Grant abuse on Microsoft 365. 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). →
  3. 03CVE-2026-42945 NGINX Rift, in-the-wild exploitation confirmed by VulnCheck honeypots. 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). →

01Active threats, incidents & disclosures1 item

NOTABLEupdatedNATOB2

THORChain vault drain, about $11M across nine chains, GG20 Threshold Signature Scheme flaw suspected (Switzerland-based protocol)

On 2026-05-15 an attacker drained approximately $11M, by THORChain's initial indications protocol-owned funds only, from THORChain, a Switzerland-based decentralised cross-chain liquidity protocol founded in 2018, after one of its six vaults was compromised, 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, supported by analysis from PeckShield, Cyvers and security teams collaborating with THORChain's core developers according to CryptoTimes's post-mortem synthesis on 2026-05-17, is a GG20 Threshold Signature Scheme (TSS) implementation flaw: a validator node that had joined the active set only days before the attack is flagged as the likely entry point, suspected of gradually leaking vault key shards during keygen and signing rounds until enough key material could be reconstructed offline to forge outbound vault signatures without triggering normal quorum checks (CryptoTimes, 2026-05-17). THORChain's Incident Update #1 on 2026-05-16 confirmed the malicious-node vector, CryptoTimes reports (CryptoTimes, 2026-05-17). 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 (CryptoTimes, 2026-05-17). 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 (TRM Labs, 2026-05-15). TRM notes that THORChain has become the bridge of choice for laundering North Korea's largest thefts, including the $1.5B Bybit and nearly $300M KelpDAO hacks, but no North Korean attribution is confirmed for this event (TRM Labs, 2026-05-15). THORChain said initial indications were that user funds were safe and only protocol-owned funds were affected (The Record, 2026-05-15). Two related but separate 2023 disclosures showed that a single malicious participant in GG18/GG20 threshold signing can extract other parties' key material. Fireblocks' CVE-2023-33241 rests on parties not checking that a participant's Paillier modulus is well formed, which Fireblocks recommends detecting with a suitable zero-knowledge proof (Fireblocks, 2023-08-09). Verichains' TSSHOCK attacks exploit weak or insecurely implemented zero-knowledge proofs, such as ambiguous transcript encoding and a reduced number of proof iterations, in most GG18, GG20 and CGGMP21 implementations by Verichains' account (Verichains, 2023-08-10). If the working theory holds, the THORChain exploit is that class of weakness in production, though CryptoTimes says only that the attack "appears to have involved" key-material leakage (CryptoTimes, 2026-05-17).

THORChain officials said the investigation into the incident is ongoing but explained that one of their six vaults was compromised, leading to a loss of about $10.7 million.

The Record

At the time of writing, TRM has not attributed the May 15 exploit to any specific actor.

TRM Labs

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.

CryptoTimes
Correctionrun 2026-09-30T0639Z-auditsourcesbodyclassificationtechniquessummaryevidenceevent_dateprioritytitleheadline

The analysis above described CVE-2023-33241 as part of the TSSHOCK class. CVE-2023-33241 is Fireblocks' GG18/GG20 Paillier-key disclosure (Fireblocks, 2023-08-09), and TSSHOCK is Verichains' separate set of key-extraction attacks (Verichains, 2023-08-10). Fireblocks' flaw lies in an unchecked Paillier modulus, which it recommends detecting with a suitable zero-knowledge proof, while TSSHOCK exploits weak or insecurely implemented zero-knowledge proofs. Both let a single malicious participant extract key material (Fireblocks, 2023-08-09; Verichains, 2023-08-10).

The account of the attack above was also narrowed to its sources. The Record reports a compromised vault. The malicious validator node is the vector THORChain's first incident update confirmed, according to CryptoTimes, and the GG20 flaw is the working theory CryptoTimes reports, supported by PeckShield, Cyvers and security teams working with THORChain rather than Chainalysis (CryptoTimes, 2026-05-17). TRM Labs calls THORChain the bridge of choice for laundering North Korea's largest thefts without naming the Lazarus Group or saying such activity dominates (TRM Labs, 2026-05-15).

threat18 May 05:00Zmulti-sourceOpen finding →
Sources: The Record, 2026-05-15 · TRM Labs, 2026-05-15 · CryptoTimes, 2026-05-17 · Fireblocks · Verichains
CRITICALCVE-2026-42897exploitedupdatedNATOA1

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.

The Exchange Emergency Mitigation Service will provide mitigation automatically, and is on by default. If it is not already enabled on your Exchange Server, you need to enable Exchange Emergency Mitigation Service.

We are working on developing and testing a more permanent fix which we will provide when it meets our quality standards.

Microsoft Exchange Team Blog 2026-07-14

The messages exploit CVE-2026-42897, a vulnerability in Outlook Web Access in which the server does not adequately sanitize HTML in the message body. This allows a loader piece of JavaScript to use the onload= event handler to parse the rest of the message body, assemble a Base64 fragment, and execute it as encoded JavaScript.

This persistent access lives on the server-side and requires deliberate removal from the Exchange server; credential rotation and even full re-imaging of the targeted user's device will not evict the actor.

Proofpoint 2026-07-29

Installing the July 2026 update does not automatically remove already applied CVE-2026-42897 mitigations.

Microsoft Exchange Team Blog 2026-07-14
Updaterun 2026-07-31T0409Z-intelactionsaffected_productscvesentitiesevidencereferencesregionssectorssourcestagstechniquesbody

The May entry tracked CVE-2026-42897 as an Exchange OWA flaw whose interim protection depended on the EM Service auto-mitigation. Two things changed. Proofpoint has now attributed in-the-wild exploitation to a named Russian state-supported actor and published the implant's full mechanics (Proofpoint, 2026-07-29), and the mitigation is no longer the remediation; the July 2026 Security Update is, with the mitigation now something that must be actively torn down (Microsoft Exchange Team Blog, 2026-07-14). NCSC-CH appended the Proofpoint reporting to its own advisory on 2026-07-30 (NCSC Switzerland, 2026-07-30).

The actor is TA488, which Microsoft tracks as Void Blizzard and which this pipeline registers as LAUNDRY BEAR, the same Russian state-supported email-espionage actor a 16-nation joint advisory exposed on 2026-07-23 for its Zimbra campaign. Proofpoint assesses OWAReaper as an evolution of that campaign's ZimReaper payload, citing shared code including an identical invisible-element sizing and error-handling pattern (Proofpoint, 2026-07-29). Campaign activity began 2026-07-22 against government, telecommunications, finance, hospitality and aerospace targets across the US and Europe, using deliberately banal lure subjects with no call to action, Proofpoint reads the unusual breadth as intentional blending with bulk mail. Its stated infrastructure-creation date of March 2026 precedes Microsoft's May disclosure by two months, which is the basis for its assessment that zero-day use is feasible; that is an inference from infrastructure dating, not a confirmed finding.

Execution. The flaw is a failure to sanitise HTML in the message body, so a loader script in an onload= handler reassembles a Base64 fragment from the rest of the message and evaluates it, no link click and no attachment open, only viewing the message in OWA. The exploit and payload fragments are hidden inside the message's social-media icon elements, with next-stage data placed after # fragment markers where the browser's Base64 image parser stops reading, so the payload is not visible to casual inspection of the HTML. On execution OWAReaper first rewrites the delivered message server-side to strip the exploit content and suppresses OWA pop-ups and right-click, then enumerates the victim's address, username and settings.

Credential and token theft. It creates two invisible input elements and waits for the browser's own autofill to populate them with the saved OWA username and password. Separately it enumerates installed Outlook add-ins holding ReadWriteMailbox permission and, where one exists, abuses it to call GetClientAccessToken and obtain OAuth tokens.

Persistence, in three independent layers. Client-side, the implant writes an AES-encrypted copy of itself and a decryption wrapper into browser localStorage under a settings field of the legitimate PageDataPayload.OwaUserDefaultSettings key, which OWA itself evaluates during its own sync-restore flow, so every ordinary OWA tab-open re-launches it with no separate loader. A second client-side layer adds a hidden iframe to messages cached in OWA's offline IndexedDB store, so opening the cached message re-infects an endpoint even after a full re-image. The third is server-side and is the one that matters most: the implant calls UpdateFolder to grant Owner-level permission on every mail folder to the low-privilege "Default" preset alias that exists in every Exchange organisation. Proofpoint is explicit that this "requires deliberate removal from the Exchange server" and that credential rotation and re-imaging will not evict it.

Command and control. Two channels, both over infrastructure defenders generally trust. The implant polls GitHub's public Commit Search API every 24 hours for crafted commit messages containing the target's own email address, decrypting matches to a four-character command header that selects toolkit replacement, C2-domain rotation, or one-off code execution; in parallel it re-parses cached inbound messages every five minutes for the same command structure. Exfiltration runs primarily over HTTPS with encrypted URI paths, either relayed through a set of legitimate image-CDN domains or sent directly to the actor-controlled server when those proxies fail; if the HTTPS method fails altogether, the implant switches to DNS label tunnelling, packing the data into the subdomain labels of ordinary DNS queries for an actor-controlled domain. Notably, Proofpoint states there is no mass mailbox exfiltration here, unlike the Zimbra campaign, which is why this entry maps browser-session and credential-access behaviour rather than bulk email collection.

Patching. The permanent fix is the July 2026 Security Update, available as Exchange SE RTM publicly and for Exchange 2019 CU14/CU15 and Exchange 2016 CU23 only through the Period 2 Extended Security Update programme; organisations that were enrolled only in Period 1, which ended in April 2026, do not receive it (Microsoft Exchange Team Blog, 2026-07-14). Microsoft's own vulnerability record scores the flaw 8.1 and marks it exploited (Microsoft Security Response Center, 2026-07-14). Installing the update does not remove a previously applied mitigation: administrators who used the EM Service must remove the M2.1.0 IIS rules through the documented rollback, and those who ran the downloadable mitigation script must run its rollback. The known operational side effects of the mitigation era (broken OWA calendar printing, inline-image rendering problems, OWA-light failing, and false-unhealthy calendar-proxy health alerts) only clear once both steps are done, so a server left on mitigation-only status keeps them indefinitely (Microsoft Exchange Team Blog, 2026-05-14).

Detection. The highest-value signal is in mailbox audit and Exchange Web Services telemetry: a folder-permission change granting Owner rights to the "Default" alias, applied across many folders of one mailbox in quick succession. Client-side, monitor for writes to the OWA user-default-settings localStorage key outside the browser's own sync flow, and for OWA sessions in which invisible form inputs are created and immediately populated. On the network side, two egress patterns stand out from a mail client's normal behaviour: repeated polling of a public source-code hosting search API on a roughly daily cadence, and DNS queries with the label-length and entropy profile of tunnelled data.

Triage: OWA legitimately reads and writes its own settings keys constantly, so the presence of localStorage activity is not the signal; the discriminator is the specific settings-field path carrying an encrypted blob, and its correlation with a message open. For the server-side artifact the discrimination is cleaner: administrators do grant folder permissions, but they grant them to named users or groups for a specific folder, not Owner rights to the built-in "Default" alias across an entire mailbox. Treat any such grant as compromise until proven otherwise.

Improvementrun 2026-08-30T1312Z-auditactionsclassification

This entry now carries a source-reliability rating, which it predates: A1 on the NATO Admiralty scale. The letter reflects Microsoft's own advisory for its own product, the number reflects independent corroboration, since Proofpoint analysed the implant separately from Microsoft's disclosure and NCSC-CH restated that analysis for its own constituency. Nothing in the assessment or the remediation guidance changes; the rating makes explicit what the sourcing already supported.

Builds on: 16-nation advisory: Russia's LAUNDRY BEAR exfiltrates government mail through a view-based…

vulnerability18 May 05:00Zmulti-sourceOpen finding →
Sources: Microsoft Exchange Team Blog, 2026-05-17 · Microsoft MSRC · Proofpoint · NCSC Switzerland, Cyber Security Hub · Microsoft Exchange Team Blog · Microsoft Security Response Center
HIGHCVE-2026-42945exploited

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.

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.

ctipilot v2 brief (migrated)
vulnerability18 May 05:00Zmulti-sourceOpen finding →
Sources: The Hacker News, 2026-05-17 · F5 PSIRT K000161019 · Security Affairs, 2026-05-14 · NCSC-CH Security Hub post #12575
NOTABLECVE-2026-0300exploited

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.

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.

ctipilot v2 brief (migrated)
vulnerability18 May 05:00Zsingle-sourceOpen finding →
Sources: Palo Alto Networks PSIRT, CVE-2026-0300

03Deep dive1 item

HIGH

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.

Doing so authorizes the attacker to register a rogue device with the victim's Microsoft 365 account, giving them unrestricted access to the victim's data and services, including email, calendar, and cloud file storage.

BleepingComputer

The user's MFA worked exactly as designed. There is no proxy, no credential capture, no fake Microsoft page.

eSentire Threat Response Unit
threat18 May 05:00Zmulti-sourceOpen finding →
Sources: BleepingComputer, 2026-05-17 · eSentire Threat Response Unit, 2026-05-12

04Action items5 items

Verification & coverage notes1 run

2026-05-18-2eabc1cf · Claude Opus 4.7 · 5 entries published

  • Coverage window: standard daily (gap to prior brief 2026-05-17 ≈ 24 h; window_hours = 36). Quiet Sunday-into-Monday, § 2 and § 3 are intentionally empty per PD-11.
  • Items dropped (sub-agent returned but failed Phase 2 / dedup / recency):
    • SEPPmail CVE-2026-44125 / 44126 / 44127 / 44128 / 44129 / 7864 cluster (NCSC-CH post #12551, 2026-05-08); already covered in the 2026-05-09 deep dive and the CVEs are all in cves_seen.json; the NCSC-CH advisory date (2026-05-08) is 10 days outside window_hours = 36; dropped, no in-window delta.
    • Windows YellowKey / GreenPlasma zero-days (NCSC-CH post #12574, 2026-05-14), already covered in the 2026-05-15 § 1; no fresh in-window development.
    • DHTMLX CVE-2026-41553 / 41552 / 7182, already covered as a TL;DR item in 2026-05-17; CERT-PL advisory date 2026-05-15 sits at the edge of window but the coverage is already current.
    • NCSC-CH weekly review Week 19 (advance-fee scam, double-phishing awareness items); primary-source date 2026-05-12 is outside window_hours; awareness-class content with no fresh defender action.
  • Single-source items: [SINGLE-SOURCE] CVE-2026-0300 PAN-OS § 4 UPDATE; sole primary source is the Palo Alto Networks PSIRT advisory (vendor-authoritative; national-CERT carve-out does not apply but vendor-PSIRT is itself the primary disclosing party).
  • Included with reduced confidence (no in-window primary): none in this brief; the three out-of-window S3 items were dropped rather than promoted.
  • Out-of-window research deferred to weekly summary (or next-week daily if material develops):
    • The DFIR Report, 2026-05-11, EtherRAT blockchain-C2 + TukTuk SaaS-C2 chain ending in Gentleman ransomware; novel detection-engineering content (EtherHiding / Arweave dead-drop / multi-SaaS C2 fingerprints) but source is 7 days outside window_hours.
    • Microsoft Security Blog, 2026-05-12, 123-day MSP-mediated intrusion via HPE Operations Manager with malicious Windows Network Provider DLL and LSA password-filter persistence; high relevance to public-sector outsourced IT but 6 days outside window_hours.
    • Unit 42, 2026-05-11, Active Directory Certificate Services ESC1 + shadow-credential exploitation attributed to Fighting Ursa (APT28); 7 days outside window_hours.
  • Contradictions surfaced: CVSS scoring for CVE-2026-42945 NGINX Rift differs across primaries; NCSC-CH lists CVSS 4.0: 9.2 Critical while NVD currently has no published score; The Hacker News and Security Affairs cite the F5 advisory's CVSS 4.0 base of 9.2 used in this brief. CVSS 3.1 score reported by NCSC-NL feed is 8.1. Brief uses the CVSS 4.0 score most widely cited by national-CERT sources.
  • Sub-agents that didn't return on time: none, S1 (348 s), S2 (677 s), S3 (576 s), S4 (679 s) all returned inside the 30-min hard cap.
  • Candidate sources surfaced this run (one new candidate maximum per PD-3.6): depthfirst (depthfirst.com), AI-assisted vulnerability research, primary disclosure source for CVE-2026-42945 NGINX Rift cited by NCSC-CH; recorded as status: candidate in sources/sources.json. A second candidate (cryptotimes) was surfaced by S4 for THORChain technical post-mortems and is held for a future run per the one-candidate-per-run cap.
  • Coverage gaps: cisa-kev (bridge subcommand returned no in-window adds beyond CVE-2026-20182 / CVE-2026-42897 already covered); apple-security (no in-window emergency update); chrome-releases (no in-window emergency update); akamai-sirt (RSS 403, no in-window content corroborated via search); trendmicro-research (feed parse error, no in-window content corroborated via search); sophos-xops (HTTP 503, no in-window content corroborated via search); inside-it-ch (host 403, no in-window CH-specific incidents); cert-eu (most recent advisory 2026-05-06; feed empty in window); ncsc-ch weekly-review-kw20 (Week 20 review not yet published as of 2026-05-18T04:50Z); cert-fr actu (feed appears stale, items dated Sep–Oct 2025); sec-disclosures-edgar (Item 1.05 search returned zero filings for 2026-05-15 → 2026-05-18, US weekend); ico-uk (no new enforcement actions in window); cnil-fr (no new enforcement decisions in window); databreaches-net (host 403, WebSearch fallback used per documented mitigation).

Unmatched action items (migrated)

  • 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.

Migrated from briefs/2026-05-18.md (v2).