Unauthorized Entra Access or Role Changes Push ConnectWise Past BeyondTrust

Take the exploit-feasibility and intrusion-scoping lens across today's infrastructure queue. Lead with the NEW BeyondTrust evidence: CVE-2026-102764 was exploited as a zero-day against two Remote Support customers through 26.2.3, followed by privilege escalation, lateral movement, SAWFLY/BARECLAW deployment, and artifact deletion. Distinguish exposure, suspected compromise, and confirmed compromise; state when isolation or rebuild is justified. Then rank PwnEscape CVE-2026-99999 (patched, no known exploitation, affected range unclear), actively exploited SiteGuard CVE-2026-106931, Nextcloud CVE-2026-110447, and Apple CVE-2024-44308. Give a decision-ready tonight/next-72-hours order, challenge the source-pack priority where warranted, and do not recap headlines.

The BeyondTrust chain closes: zero-day entry against two Remote Support customers, privilege escalation, lateral movement, SAWFLY/BARECLAW deployment, then artifact deletion. Exposure means an affected, reachable appliance without corroborating telemetry—patch or remove external access tonight and hunt from centralized logs. Suspected compromise means unexplained privileged activity, lateral movement, matching payload indicators, or deletion gaps; isolate immediately. Confirmed compromise means verified exploit execution, malware deployment, privilege escalation, or movement into another host. Rebuild is justified for confirmed privileged compromise, or when deletion makes integrity impossible to establish. Exposure alone does not justify a rebuild.

My order for tonight is: 1) BeyondTrust suspected/confirmed systems; 2) SiteGuard CVE-2026-106931; 3) Nextcloud CVE-2026-110447; 4) Apple CVE-2024-44308; 5) PwnEscape CVE-2026-99999. SiteGuard is being exploited to execute commands as SYSTEM/root—patch or isolate reachable servers now. Nextcloud’s built-in CODE Server is also under active exploitation, so remove reachability or patch tonight. Apple’s issue is actively exploited against Intel Macs, but scope it to actually affected devices.

I reject the source-pack elevation of PwnEscape over those actively exploited flaws. It is patched, but the affected range is unclear and there is no reported exploitation. A guest-to-host escape also starts with control inside a KVM guest; that is a serious door, but it is not the same as attackers already walking through it. Exception: hostile multi-tenant KVM hosting moves PwnEscape ahead of Apple, because untrusted tenants already satisfy that guest-side precondition. During the next 72 hours, finish KVM version mapping and patching, while BeyondTrust scoping follows the lateral path into adjacent hosts and treats missing local evidence as potentially deliberate deletion—not proof of cleanliness.

Analyze the ConnectWise cloud identity incident as a trust-chain failure: alleged abuse of a vendor-managed client assertion, 173 Microsoft 365 tenants accessed, suspicious sign-ins across nearly 1,000 Entra tenants, more than 300 successful authentications, one Global Administrator escalation, and attacker-added long-lived application secrets. Define the exact containment and hunt sequence for a tenant tonight, including why disabling the original application may be insufficient. Separate confirmed facts from Huntress scope indicators, name the evidence that warrants tenant-wide credential or federation recovery, and make a firm call on assumed breach versus exposure-only handling.

What is confirmed versus reported: ConnectWise confirms unauthorized access to application identities associated with Cloud Backup and says it disabled seven application identities and revoked service certificates. Huntress independently reports 173 Microsoft 365 tenants accessed, suspicious activity across nearly 1,000 Entra tenants, more than 300 successful authentications, one Global Administrator escalation, and attacker-added long-lived application credentials. Those numbers are Huntress scope indicators—not yet vendor-confirmed totals. Todyl corroborates application-only Microsoft Graph sign-ins using clientAssertion, Python-urllib/3.12, Conditional Access: notApplied, and related session identifiers. Huntress calls the compromised material an API secret, while Todyl records clientAssertion; therefore, the safe conclusion is compromise of vendor-managed application credentials, not a proven single credential type. No user MFA challenge exists in this app-only trust path.

Tonight’s containment sequence:

1. Preserve, then block immediately: Export service-principal sign-ins, Entra audit logs, Microsoft 365 Unified Audit logs, application/service-principal manifests, OAuth grants, owners, credentials, role assignments, Conditional Access policies, and federation configuration from October 15 through the present—or the full available retention window. Record object IDs and credential metadata before changing them.
2. Disable every listed ConnectWise enterprise application, not merely the application seen in one event. Remove its tenant-side app-role assignments/admin consent and block workload authentication. Preserve the objects rather than deleting them until evidence collection is complete.
3. Hunt successful application authentications: Pivot on the seven application IDs, Microsoft Graph resource access, clientAssertion, Python-urllib/3.12, Conditional Access: notApplied, Todyl’s session pattern, unfamiliar hosting-provider addresses, and the reported incident window. Failed attempts indicate exposure; successful authentications establish unauthorized tenant access.
4. Trace persistence from every successful event: Search audit activity for added passwordCredentials or keyCredentials, new applications/service principals or owners, new OAuth grants, added directory roles—including Global Administrator—changed authentication methods, mailbox delegation/forwarding, new users, Conditional Access changes, and modified federation domains or signing certificates.
5. Eradicate every derivative identity: Disable rogue applications and service principals; remove attacker-added credentials, owners, grants, and role assignments. For affected users, disable as necessary and revoke sessions and refresh tokens before resetting credentials and re-registering authentication methods. Password rotation alone is not containment.
6. Review accessed resources: Correlate Graph and Unified Audit activity for mailbox access, searches or exports, inbox rules, SharePoint/OneDrive access, Teams activity, and directory enumeration. Reconnect Cloud Backup only through newly established vendor credentials and freshly reviewed consent.

Disabling the original application is insufficient because the reported long-lived secrets and Global Administrator escalation represent independent trust paths. An added credential on another application can continue authenticating after the original ConnectWise service principal is blocked; an elevated identity can also create further applications, grants, authentication methods, or federation persistence. Tenant-wide identity recovery is warranted if evidence shows the Global Administrator assignment was exercised, privileged application credentials or owners were added, federation settings or signing material changed, authentication methods or Conditional Access were modified, or logging gaps prevent scoping those actions. Federation recovery then means replacing signing/decryption certificates and re-establishing the relying-party trust—not simply resetting passwords.

My firm call: any tenant with a successful unauthorized application authentication is an assumed breach, even if no destructive action is visible. The initial blast radius should be limited to the application’s effective permissions unless privileged persistence is found. Exposure-only handling is defensible solely where complete sign-in and audit evidence shows attempts failed and no identity, consent, role, credential, or federation mutation occurred.

Take the financial-crime and recovery lens on Cysic: database/message-processing abuse allegedly enabled minting 10 million unbacked CYS on BNB Smart Chain, about $727,000 moved to Ethereum, receiving address blacklisted, bridge suspended. Explain the live containment, on-chain tracing, exchange notification, supply reconciliation, and evidence needed before reopening. Briefly contrast this backend-authority failure with Qubic's predictable wallet seeds and the unconfirmed Lazarus narrative around Upbit. Which issue is operationally urgent today, and which attribution claims should remain out of executive messaging?

Halil, the Cysic blacklist is containment—not recovery. The attacker allegedly minted 10 million CYS on BNB Smart Chain, sold 7.2 million through routes including PancakeSwap and OKX’s DEX aggregator, and moved roughly 306.6 ETH—about $727,000—to Ethereum. Cysic reportedly blacklisted the receiving address 76 minutes after the mint, but most funds had already moved. The bridge suspension prevents additional fraudulent messages while investigators trace every BSC-to-Ethereum hop. Freeze requests should go immediately to any identified custodial exchange or issuer; a DEX aggregator notification is useful for intelligence, but it does not itself freeze self-custodied ETH.

Before reopening, Cysic needs transaction-level accounting for all 10 million unauthorized tokens: tokens sold, remaining balances, LP exposure, burned or blacklisted amounts, attacker proceeds, and any exchange deposits. It must also reconcile bridge escrow against canonical CYS supply and inspect every message ID, nonce, database modification, signer action, and mint event for replay or additional fraudulent instructions. The reopen evidence should include a confirmed root cause, preserved database and access logs, proof that authorization was moved out of attacker-controlled backend state, key rotation where relevant, independent testing, and a published loss-and-compensation ledger. A blacklisted balance must not be booked as recovered until control of the asset is actually obtained.

Qubic is a different failure class: predictable wallet seeds imply compromised private keys, so affected users must migrate to newly generated wallets; no backend patch can make an exposed seed secret again. If ranking immediate loss prevention, Qubic is more urgent because funds may remain drainable, while Cysic’s bridge is already suspended. Cysic’s urgent decision is not to reopen prematurely. The Upbit–Lazarus claim should remain outside executive attribution language: the available reporting describes that linkage as expert speculation, not confirmed attribution. Likewise, Cysic’s database/message-processing explanation remains preliminary until forensic evidence establishes the access path and authority used.

Assess Hirudo's Android banking-app replacement chain for seven Indonesian banks: lure apps, fake update prompts, Accessibility abuse, removal of the legitimate app, malicious replacement, concealed screen recording, and apparent return of genuine certificate information during integrity checks. Identify the controls this likely bypasses, the telemetry that still exposes it, and the concrete actions banks, app teams, and customers should take now. Make a position on whether ordinary mobile-app attestation is still useful here or dangerously reassuring.

The chain is clever because it does not defeat Android package signing directly: the victim is manipulated into uninstalling the genuine bank app, removing signature continuity, and then installing a trojanized replacement. Inside that replacement, a YAHFA/Dobby-based hooking layer reportedly substitutes genuine certificate data and suppresses Accessibility, screen-capture, and Play Integrity results. Hirudo then uses Accessibility for interaction and WebRTC for live screen access. In effect, it bypasses app-local anti-tamper, signature, Accessibility-abuse, and capture detection—not Android’s sandbox itself. Reporting refers to eight copied banking apps; I cannot resolve whether those map to exactly seven banks from the available evidence. (ThreatFabric (opens in new tab), SecurityWeek (opens in new tab))

It is still exposed by telemetry outside that hooked process: rapid uninstall/reinstall of a bank package, a changed signer or app instance, sideloaded installer provenance, newly enabled Accessibility services, lure/dropper packages such as com.agbbh.kjdrttt, com.onev.vip, com.koishort.app, and com.zoyatv.app, and RAT packages including com.zk7qpx.mv9wlt and com.r9nkvx.qw2mpl. Banks should also hunt for fresh device enrollment followed by unusual payments, remote-control timing patterns, and WebRTC/C2 traffic. Crucially, the bundled attestation keybox is reportedly leaked and two certificates are marked compromised by Google, meaning revocation-aware server-side validation can still reject it. (ThreatFabric (opens in new tab), BleepingComputer (opens in new tab))

Banks should immediately ingest the published hashes and package indicators, invalidate sessions after suspicious app re-enrollment, step up authentication through an independent channel, and place transaction-risk controls above the mobile client. App teams should move trust decisions out of the app process: verify package identity and fresh, request-bound integrity evidence on bank servers; enforce certificate revocation; bind device keys to enrollment; and treat a signer, key, or app-instance change as hostile until reverified. Customers who saw an unsolicited “update” should stop using that device for banking, contact the bank through a known number, revoke sessions and rotate credentials from a clean device, remove suspicious Accessibility services and sideloaded apps, and factory-reset the handset if the RAT was installed.

My position: ordinary app attestation remains useful, but a green verdict is dangerously reassuring when it is generated, interpreted, or enforced inside the same process the attacker has hooked. Fresh, server-verified, revocation-aware attestation is one fraud signal—not proof that the screen, input path, or transaction is trustworthy.

Assess the reported French supermarket freezer manipulation as an OT safety and continuity event: hundreds of internet-connected units allegedly driven above 100°F with multimillion-dollar spoilage. Separate verified facts from unresolved access-path claims, then give the first-hour response that preserves food safety and evidence without creating unsafe shutdowns. Address segmentation, vendor remote access, manual temperature controls, fleet-wide blast-radius checks, and the evidence needed before reconnecting. Briefly say whether the Booz Allen AI/ICS lab result changes today's operating response or remains planning context.

The physical risk comes first: loss of refrigeration can make food unsafe, while an indiscriminate shutdown can also stop otherwise healthy cooling. Fact: reporting links attacks on European Danfoss refrigeration controllers with losses in the tens of millions, and CISA documents remotely exploitable authentication, command-injection, and configuration-control flaws in AK‑SM 8xxA systems. Unknown: I do not have authoritative confirmation of the claimed store count, temperatures above 100°F, precise losses, actor, or initial-access path. The published Danfoss vulnerabilities make exploitation plausible, but they do not prove those CVEs were used; stolen credentials, a vendor portal, VPN access, or another management path remain viable hypotheses.

In the first hour, appoint a joint refrigeration, food-safety, and incident-response lead. At Purdue Levels 2–3, block suspect Internet and vendor-management sessions while preserving Level 1 local controller operation—do not reboot or power down the refrigeration fleet. Have trained site personnel verify setpoints and actual case temperatures with independent instruments, place affected stock under food-safety hold, and use validated local/manual control only where operating procedures permit it. Before changing anything, preserve controller configurations, alarms, audit logs, remote-access and identity logs, firewall records, vendor-portal activity, and timestamps; capture network traffic only if that will not disrupt control communications.

Then check the entire fleet for the same controller model and firmware, shared vendor tenants or credentials, altered setpoints, disabled alarms, configuration drift, unexpected users, and common source addresses. Reconnection requires a known-good configuration, supported firmware or documented compensating controls, revoked sessions and rotated credentials, restricted VPN/jump-host access rather than direct Internet exposure, and clean monitoring evidence. Test segmentation and firmware changes off-process first: breaking alarm, defrost, or compressor-control communications can create a worse safety event than the intrusion.

The Booz Allen result remains planning context, not evidence about this incident. Its models achieved all eight objectives in an isolated, multi-vendor OT lab where humans approved exploits and physical actions; that strengthens the case for limiting traversal and detecting consequential setpoint changes, but it does not alter today’s first-hour procedure or resolve the access path.

Take the software and hardware supply-chain lens. For the chalk/debug maintainer phish and Shai-Hulud propagation through hundreds of npm packages, state how teams should inventory affected versions, isolate builds, preserve CI evidence, rotate publishing/GitHub/cloud credentials, and validate downstream artifacts before release. Then contrast the Ledger/CryptoBillis hardware-wallet implant claim: Ledger confirms reseller-linked compromise and sales suspension but provides no affected models or technical indicators. Tell us what customers can safely do without overstating the reported >$100 million loss or treating every Ledger device as compromised.

Halil, for Chalk/Debug and Shai-Hulud, inventory must be package name + exact version + integrity hash, not merely “we use npm.” Export every lockfile and SBOM, then recursively inspect workspaces, package caches, container layers, build artifacts, and transitive dependencies against the evolving affected-version lists. The CSA advisory demonstrates why exact matching matters, listing specific malicious releases such as [email protected] and [email protected]. Immediately stop releases that intersect the exposure window; quarantine runners, caches, and produced artifacts; and rebuild on clean infrastructure from known-good lockfiles and verified package archives.

Before cleanup, preserve package tarballs, lockfiles, CI logs, GitHub audit logs, runner images, build provenance, registry events, and network telemetry—evidence specifically recommended in JFrog’s response guidance. Then revoke and rotate npm publishing tokens, GitHub PATs and deploy keys, cloud credentials, Vault/Kubernetes secrets, SSH keys, and any signing material accessible to those runners. The Tensorlake advisory shows that Shai-Hulud variants sought this broad credential set, so rotation scope should follow what the build identity could access, not only what investigators know was stolen. For every downstream release built during exposure, quarantine it, compare its SBOM and provenance with a clean rebuild, scan for malicious lifecycle code and unexpected outbound behavior, and issue fresh signatures or attestations only after validation. A valid old signature proves who signed the artifact—not that the compromised build was clean.

The Ledger case is materially narrower. Fact: Ledger confirmed at least one unauthorized implant in a device sold through CryptoBilis, while the reseller suspended hardware-wallet sales; affected models were not identified, and Ledger’s normal authenticity check may not detect this form of tampering. Assessment: this is presently a reseller/distribution-channel failure, not evidence that every Ledger device is compromised. CryptoBilis customers should not initialize unused devices; those already used should move assets promptly to an independently sourced signer initialized with a completely new seed, never enter the old recovery phrase into a website or app, preserve the suspect device and purchase records, and follow Ledger’s case-specific instructions. Customers outside that channel should verify purchase provenance and monitor Ledger guidance rather than destroy or replace devices indiscriminately. Unknown: there is no public model/serial-range indicator sufficient for customers to clear a device themselves. The loss must also remain qualified: CoinDesk cited third-party estimates of $86–93 million, while Bitquery claimed about $102 million; Ledger had not confirmed an official total.

Interrogate the attribution and evidence thresholds across the lead stories. For BeyondTrust CVE-2026-102764, explain what the two-victim SAWFLY/BARECLAW evidence can support about a China-linked campaign versus direct state tasking, and what is genuinely new relative to the earlier exposure-and-patch posture. Also flag any source-pack claims we should deliberately keep at monitoring status—especially Lazarus speculation around Upbit, Handala's Israeli military breach claim, and nation-state split/private-model AI architectures. Give decision implications, not a campaign recap.

The two-victim record supports high confidence that CVE-2026-102764 was operationalized in a repeatable campaign, with SAWFLY, BARECLAW, root escalation, credential access, tunneling, and log deletion mapping to T1190, T1505.003, T1548.001, T1555, T1572, and T1070.001. I assign moderate confidence to the ARMORY CASTLE/UNC5221 China nexus, but low confidence to direct Chinese state tasking: two victims and shared tooling establish campaign continuity, not the sponsor or command relationship. What is genuinely new is observed post-exploitation beginning August 29—not merely vulnerable exposure—so patching alone is inadequate: hunt historically, rotate appliance-accessible secrets, examine downstream managed systems, and rebuild where root compromise is established.

Keep three claims at monitoring status. Upbit’s Lazarus attribution is low confidence, resting on sophistication, speed, and automation rather than actor-specific infrastructure or malware. Handala’s Israeli military breach remains an unverified self-claim reported without technical intrusion evidence or independent confirmation. The private/split-model AI architecture story is also monitoring-grade: the source pack contains one context-only Team8 account, insufficient for a generalized nation-state capability judgment. None should drive actor-specific response decisions until corroborating infrastructure, artifacts, telemetry, or authoritative findings appear.

Rank the board-level operational priorities across PwnEscape CVE-2026-99999, BeyondTrust, ConnectWise, French freezer manipulation, and the 1,413-CVE Microsoft patch wave. Use concrete exposure conditions that reverse the ranking—for example untrusted KVM guests, internet-reachable Remote Support, ConnectWise-integrated Entra tenants, or affected freezer fleets. Translate each into a downtime, loss, or trust consequence and make one firm call on what a CISO with 30 minutes should fund or interrupt tonight. Do not rank by CVSS or patch volume.

My board ranking is 1) BeyondTrust, 2) PwnEscape, 3) ConnectWise, 4) French freezer manipulation, 5) Microsoft’s 1,413-CVE wave. BeyondTrust leads where Remote Support is internet-reachable: exploitation has been observed, with reported credential theft, root escalation and downstream pivoting. The business response is an immediate support outage plus a potentially enterprise-wide trust reset. PwnEscape becomes #1 for hosting or cloud operators running untrusted KVM guests: guest-to-host escape turns one hostile tenant into a cross-tenant breach, requiring host evacuation and potentially days of service disruption. ConnectWise becomes #1 if its integration into Entra has privileged tenant access and there are compromise indicators; disabling that trust could interrupt administration for hours or days, but leaving it enabled risks losing confidence in the identity plane.

Freezer manipulation becomes #1 locally where affected controllers operate an active cold-chain fleet without independent temperature verification: the consequence is immediate manual inspection, distribution holds, spoilage and possible safety exposure. The Microsoft wave stays last because 1,413 patches is workload, not risk; it jumps upward only if the estate contains an exploited flaw on an internet-facing or Tier-0 identity system. I found no current data establishing affected ConnectWise tenant counts, freezer-fleet scale, remediation duration, or defensible loss figures, so any dollar estimate would be invented.

With 30 minutes, I would fund and authorize an emergency interruption of every internet-reachable BeyondTrust Remote Support instance tonight—restrict access, apply BT26-05, preserve evidence, hunt for persistence, and rotate exposed administrative credentials and secrets. If there is evidence of compromise, patching alone does not restore trust. The only automatic override is a confirmed Entra control-plane compromise or an affected freezer fleet already operating outside safe limits.

Close the room with one executable 24-hour defense order, using the panel's findings rather than recapping headlines. Alex says the BeyondTrust kill chain is closed and exposed Remote Support must be treated differently from confirmed malware/lateral movement. Marcus says disabling ConnectWise's original identities may not remove attacker-added app secrets. Viktor says Cysic's blacklist is containment, not recovery. Nadia says Hirudo manipulates users into uninstalling the genuine app rather than breaking Android signing. Sara puts refrigeration safety and manual controls before indiscriminate shutdown. Tomas requires npm scoping by exact version and hash plus CI/credential recovery. Lena supports a repeatable China-linked BeyondTrust campaign but not direct state tasking. Pierre ranks BeyondTrust first and PwnEscape second, ahead of ConnectWise, but that ordering should reverse when a tenant shows unauthorized app credentials or Global Administrator activity. Give exact decision gates for: (1) isolate/rebuild/hunt BeyondTrust; (2) revoke and independently enumerate ConnectWise persistence; (3) patch or constrain untrusted KVM guests for CVE-2026-99999; (4) triage active SiteGuard CVE-2026-106931, Nextcloud CVE-2026-110447, and Apple CVE-2024-44308; and (5) contain npm, Hirudo, Cysic, and freezer incidents without pretending one generic playbook fits all. Be concise enough for a CISO with 30 minutes. Explicitly challenge any panel priority you think is wrong.

0–2 hours: Default priority is BeyondTrust first, but I challenge Pierre’s fixed ordering: ConnectWise becomes first immediately if Entra shows an unauthorized application secret, app-only access, role assignment, or Global Administrator activity. For BeyondTrust, confirmed malware, exploit artifacts, credential access, or lateral movement → isolate the appliance, preserve logs/snapshots, revoke reachable credentials, hunt adjacent systems, then rebuild from trusted media. Mere internet exposure without indicators → remove public reachability or strict-allowlist it, preserve evidence, hunt, and apply the verified update after a short canary; exposure alone does not justify destroying evidence or rebuilding. For ConnectWise, revoke the original integration credentials but independently query Entra for every service principal, secret, certificate, owner, consent grant, directory role, and app-only sign-in—not just what ConnectWise reports. Any attacker-added credential or privilege assignment triggers removal, token/session invalidation, tenant-wide hunting, and recovery as an identity compromise. The reported incident included persistence through added long-lived secrets, so disabling the original application is insufficient. BeyondTrust (opens in new tab) ConnectWise (opens in new tab)

2–8 hours: For CVE-2026-99999, untrusted guest plus an affected guest-controlled host-networking path → stop new scheduling, migrate or shut down those guests, dedicate the hosts, and prevent guest access to host/management networks until a tested kernel fix is deployed. Trusted-only hosts can enter canary patching and monitoring; I found no verified fixed kernel versions in the available evidence, so do not accept an unverified package as remediation. PwnEscape (opens in new tab) For SiteGuard CVE-2026-106931 and Nextcloud CVE-2026-110447, I found no current advisory or patch data on this: if an internet-facing instance cannot be version-mapped within two hours, remove its external exposure and preserve logs rather than claiming it is patched. CVE-2024-44308 has reported active exploitation against Intel Macs; affected, internet-active endpoints that cannot be confirmed on a vendor-fixed build should be isolated from risky browsing until MDM confirms remediation. Apple (opens in new tab)

8–24 hours: Scope npm only by the exact package, version, and hash: quarantine matching artifacts, stop only pipelines that resolved that tuple, inspect install-time execution, and rotate registry/CI/cloud credentials if the package ran or accessed secrets; rebuild from a known-good lockfile and clean cache. For Hirudo, isolate the affected phone, remove the malicious copy through MDM or controlled recovery, reinstall the genuine banking app from the official store, and reset banking credentials and sessions from a clean device—the gate is malicious installation, not Android-signing failure. npm (opens in new tab) Hirudo (opens in new tab) For Cysic, blocklisted indicators provide containment only; suspected key exposure requires key rotation and transaction reconciliation before service restoration. For freezers, keep refrigeration, alarms, and manual control operating locally; isolate remote pathways individually and shut equipment down only where a malicious command path is confirmed and a safe manual fallback exists.

Claim: Your board ranking places BeyondTrust first and ConnectWise third by default. Counter-evidence: James challenges a fixed ordering: ConnectWise should become first immediately when Entra telemetry shows an unauthorized application secret, app-only access, role assignment, or Global Administrator activity, because disabling the vendor identity may leave durable attacker persistence. Reconcile the rankings and give one concrete decision threshold a board or CISO can apply tonight.

James is right: ConnectWise moves to #1 on evidence of tenant compromise; BeyondTrust stays #1 only when ConnectWise shows no such evidence. ConnectWise’s incident reportedly affected 173 Microsoft 365 tenants and caused seven application identities to be disabled. Revoking vendor certificates prevents new authentication but does not remove credentials, permissions, owners, roles, or other persistence already created inside a tenant. That is a materially different state from exposure: it is loss of confidence in the identity control plane.

The decision threshold tonight is: one confirmed unauthorized Entra directory-write event tied to the ConnectWise identity—a new secret or certificate, service-principal owner, consent grant, or privileged role assignment. Cross that threshold and interrupt ConnectWise immediately: preserve logs, disable the service principal, revoke credentials and tokens, enumerate all related application objects, and remove unauthorized permissions before restoration. If telemetry shows none of those events, an internet-reachable vulnerable BeyondTrust instance remains first because exploitation is active. In board terms: confirmed identity persistence outranks an exposed remote-support system; exposure outranks patch volume. The cost trade-off is temporary backup or administrative downtime versus a tenant-wide trust reconstruction; I found no defensible current data to price that reconstruction in dollars.

Close the unresolved Qubic thread. What evidence can identify wallets created by the predictable-seed process, and what immediate migration, monitoring, and fund-recovery actions should apply to every potentially affected wallet? Be explicit about whether users can safely rely on the validator halt or reimbursement promises, and state what proof is needed before normal transfers resume.

Halil, Qubic’s own incident notice defines the presumptive exposure set: seeds created on an iPhone or iPad in any browser before 18 October 2026, on macOS Safari before that date, or in the Qubic iOS app before July 2025. Those wallets should be treated as compromised regardless of whether they were among the 1,404 already drained. Creation records, device/browser telemetry, application version, backups and timestamps establish exposure; controlled reproduction of the vulnerable generator can confirm it by deriving the same public wallet ID. On-chain data alone can identify drained wallets and common sweep destinations, but it cannot prove how an untouched wallet’s seed was generated.

While validators maintain the halt, affected users should create a completely new seed using independently verified, fixed software and a clean device—never import or “rotate” the old seed in place. They should prepare a verified destination and sweep the entire balance at the first authorized recovery window, then permanently retire the old wallet. Monitor both addresses and attacker destinations at every tick; preserve transaction links, wallet IDs and balances; and submit those—not seeds or private keys—through Qubic’s official claims channel. Qubic says version 4.26.4 corrected seed generation, while reporting indicates most stolen funds were contained on-chain or at MEXC, making immediate exchange preservation and freeze requests essential.

Users cannot safely rely on the validator halt: it pauses movement but does not restore secrecy to predictable keys. Nor is reimbursement assured; the reported remedy remains a Computor/community governance decision. Normal transfers should resume only after publication of the vulnerable-code boundary, independent entropy testing and reproducible test vectors for 4.26.4, signed-client verification, a final canonical ledger state, and a documented procedure preventing the attacker from winning a transfer race. Until then, every wallet matching the exposure criteria remains unsafe.