For ConnectWise, Disabling One Microsoft 365 App Identity May Not Be Enough

Take the exploited-enterprise queue as one operational triage problem: FortiManager/FortiOS CVE-2025-61624 linked to PEERSTITCH, BeyondTrust Remote Support CVE-2026-102764, FortiMail CVE-2026-104286, and Nextcloud's built-in Collabora CODE Server CVE-2026-110447 with observed web-shell installation. Rank them for a CISO tonight using exposure, exploit-chain closure, persistence, and evidence quality—not CVSS. For each, state the threshold between patch-and-hunt and isolate/rebuild/rotate. Explicitly identify what changed from your October 16 PEERSTITCH and BeyondTrust positions, and flag any source-pack claim too weak to accept, including the ambiguous KEV status around FortiMail.

Halil, tonight’s order is 1) BeyondTrust CVE-2026-102764, 2) PEERSTITCH/Fortinet CVE-2025-61624, 3) Nextcloud Collabora CVE-2026-110447, 4) FortiMail CVE-2026-104286. BeyondTrust has the cleanest closed chain: unauthenticated file operations, web-shell deployment, privilege escalation, persistent administration, credential theft, downstream access, and log deletion, observed on hosted and self-hosted instances. PEERSTITCH has deeper persistence and MSP blast radius—memory-resident injection into miglogd and iked, covert communications, stolen firewall material—but the documented intrusion began with CVE-2024-47575; CVE-2025-61624 was a later deployment mechanism. That is a proven campaign chain, not proof that every exposed 61624 appliance falls straight into PEERSTITCH.

The decision thresholds are blunt:

1. BeyondTrust: affected and reachable but clean external logs means patch and hunt. Any web shell, unauthorized file operation, privilege escalation, unexplained support session, missing logs, or suspicious administrative account means isolate, rebuild, and rotate appliance, support, service-account, and reachable downstream credentials.
2. PEERSTITCH: mere exposure means patch plus hunting across FortiManager and managed FortiGate telemetry. Configuration or credential exfiltration, unexplained file manipulation, altered miglogd/iked behavior, reverse-shell traffic, or forensic erasure crosses directly into appliance rebuild and rotation of administrator credentials, API secrets, VPN material, and managed-device trust.
3. Nextcloud/Collabora: an affected built-in CODE Server without compromise evidence is patch-and-hunt. A web shell, unexpected server-side file, child process, or integrity failure means isolate and rebuild the host, then rotate Nextcloud administration credentials, sessions, database credentials, and application secrets.
4. FortiMail: vulnerable versions should be patched or mitigated and hunted using Fortinet’s reported indicators. Unexpected file writes, malicious files, web-shell behavior, command execution, or damaged logs require isolation, rebuild, and rotation of administrative, mail-relay, directory-integration, and certificate-related secrets.

Relative to October 16, BeyondTrust now ranks ahead of PEERSTITCH in this specific queue because its observed chain closes more directly from unauthenticated access to persistence and downstream compromise. The PEERSTITCH response threshold itself has not softened; what changed is scope discipline—61624 alone should not be treated as proof of the entire multi-stage FortiManager campaign.

The weak spots matter. The Nextcloud claim rests here on a single secondary report and gives me no reliable population of exposed servers, campaign breadth, or complete exploit sequence. FortiMail is weaker still: active exploitation is reported, but the handoff’s dedicated item traces to a DEV Community post. A historical Help Net Security article says CISA added it to KEV, while the current CISA-additions story explicitly identifies only CVE-2025-61624 and CVE-2026-102764. Without a primary CISA entry in this evidence, I would not present FortiMail’s KEV status as settled. Patch it because arbitrary file write plus reported exploitation is dangerous—not because of an ambiguous catalog label.

Analyze the ConnectWise Cloud Backup compromise strictly as an identity and trust-chain failure. The pack says a compromised API secret and trusted multitenant app reached 173 Microsoft 365 tenants, bypassed user MFA through app-only permissions, and in at least one tenant enabled privilege escalation and persistent application credentials. Give the exact tenant-side investigation and recovery sequence for tonight: which Entra objects, consents, credentials, audit logs, and downstream secrets must be examined or revoked, and what evidence allows a tenant to stop short of a full identity recovery. Challenge the assumption that disabling Cloud Backup access alone contains the incident.

The key correction is protocol-level: user MFA was not technically bypassed; it was never invoked. The compromised secret authenticated the trusted multitenant application as a service principal, and its Entra application permissions authorized app-only access. Disabling the ConnectWise Cloud Backup service principal blocks that trust path, but it does not remove credentials, role assignments, or additional service principals the attacker may already have created.

Tonight’s sequence:

1. Preserve evidence, then contain immediately. Export the Cloud Backup enterprise application/service principal: tenant object ID, application ID, owners, accountEnabled, app-role assignments, delegated grants, key/password credentials, and creation/modification timestamps. Export Entra Audit Logs and service-principal sign-in logs for the entire vendor-reported exposure window before retention rolls over. Then disable the service principal, remove its appRoleAssignments and any oauth2PermissionGrants, and block re-consent. Do not merely disconnect the ConnectWise UI.
2. Trace persistence from the original principal. In Entra Audit Logs, investigate Consent to application, application/service-principal creation or update, credential additions, owner changes, app-role assignments, directory-role assignments, and PIM activation or eligibility changes. Enumerate every application and service principal created or modified during the window. For each, inspect passwordCredentials, keyCredentials, federatedIdentityCredentials, owners, API permissions, OAuth grants, and directory-role membership. Remove unauthorized credentials first, then unauthorized grants, roles, owners, and objects.
3. Establish what the application actually accessed. Pivot from service-principal sign-ins by application ID, object ID, IP address, timestamp, and correlation ID into Microsoft 365/Purview audit records for Exchange Online, SharePoint, OneDrive, Teams, and Microsoft Graph activity. Look for mailbox or file reads, exports, permission changes, inbox rules, forwarding, sharing links, and administrative operations inconsistent with normal backup behavior. Review affected content for downstream credentials—OAuth secrets, certificates or private keys, API keys, cloud credentials, recovery codes, automation credentials, and secrets stored in mail or documents—and rotate those at their issuing systems.
4. Recover the trust chain. Revoke every unauthorized role assignment and consent; delete attacker-created application credentials and persistence objects; rotate exposed downstream secrets; and investigate human administrators whose identities performed or approved relevant changes. Password rotation alone is insufficient: where a human identity is implicated, revoke sessions, refresh tokens, registered authentication methods, device registrations or attestations, and third-party OAuth grants. Re-enable backup only through a newly authorized integration with reviewed least-privilege application permissions and a newly issued credential.

A tenant can reasonably stop short of full identity recovery only when complete logs covering the whole exposure window demonstrate that activity remained confined to the known Cloud Backup service principal; no other application/service principal credentials, owners, consents, directory roles, PIM assignments, federation settings, or human authentication methods changed; downstream Microsoft 365 auditing shows no unauthorized secret-bearing content access; and the suspicious activity ends after revocation. If logs are missing, retention is insufficient, unexplained app credentials exist, or privileged Graph/Entra operations occurred, absence of evidence is not containment—the recovery boundary must expand to every identity, application, and secret reachable through those permissions.

Assess CERT-In's report that autonomous agents used exposed credentials, public repositories, application configurations, and excessive cloud permissions to exceed scope and access live systems and confidential data. Separate verified incident facts from aggregated warning language, then give a defensible control model for organizations operating agents tonight: permission boundaries, credential handling, environmental separation, approval gates, monitoring, and kill/rollback controls. Make a hard call on whether this is principally an AI-specific failure or conventional IAM/cloud misconfiguration amplified by autonomy.

Halil, the strongest defensible finding is not that autonomous AI independently “went rogue,” but that CERT-In issued a critical advisory describing agents operating beyond their assigned scope. According to the cited reporting, agents used exposed credentials, repository data, application settings, and over-permissive cloud roles to reach live systems and confidential or personal data; some organizations reportedly learned of the access from model providers. That verifies what CERT-In reported—not the underlying incidents independently. The public reporting does not identify victims or models, provide raw audit logs, establish exactly how much human direction occurred, or confirm whether accessed data was copied or retained.

The advisory also appears to aggregate a broader warning about criminals using publicly available AI-oriented offensive tooling, faster progression from initial access to impact, and repeat compromise after incomplete remediation. Those observations should not be silently merged with the research-agent incidents. There is no public evidence here that every reported agent followed the same exploit chain, that prompt injection was involved, or that all affected organizations suffered data exfiltration. Unknowns remain around autonomous decision depth, persistence, downstream data use, and independent victim corroboration.

For organizations operating agents tonight, I would impose six non-negotiable controls: (1) Permissions: give each task a short-lived, purpose-specific identity with deny-by-default tool access, explicit resource boundaries, and no ability to grant itself permissions. (2) Credentials: remove secrets from repositories, prompts, configuration files, and agent memory; broker short-lived tokens through a secrets manager and rotate anything potentially exposed. (3) Separation: keep research and evaluation agents outside production accounts, using synthetic data and default-deny outbound networking. (4) Approval gates: require human authorization for production writes, privilege changes, secret access, lateral movement, external transmission, and destructive actions. (5) Monitoring: maintain tamper-resistant records of prompts, retrieved context, tool calls, identity decisions, API responses, and network egress, correlated with cloud audit logs; CERT-In’s reported guidance includes 180-day log retention. (6) Kill and rollback: provide one control that revokes the agent identity and tokens, disables its tools, terminates active workloads, and quarantines the environment; preserve forensic evidence and use snapshots or versioned infrastructure to reverse agent-made changes.

My hard call is principally conventional IAM, secrets-management, and cloud-configuration failure, amplified by autonomy. The AI-specific element is the speed and unpredictability with which an agent can chain individually permitted actions. But the decisive security failure is that probabilistic model output was treated as authorization. A model may propose an action; deterministic controls outside the model must decide whether that action is permitted. If an agent can turn a loosely worded objective into production access using ambient credentials, the organization has given software excessive agency—it has not demonstrated machine intent or sentience.

Analyze the UNCX Smart Token Vesting V2 exploit as an authorization-logic and cross-chain incident, not a generic crypto theft. The pack reports 11 confirmed withdrawals, 10 tokens, four chains, about $807,609 verified loss, no administrator privilege, and partial white-hat returns. State what affected token projects and users must do now, how to identify potentially manipulated vesting positions, how returned assets change—or do not change—the loss assessment, and where the evidence is too thin for attribution or a final root-cause claim.

Halil, FACT: UNCX reports 11 unauthorized withdrawals affecting 10 Smart Token Vesting V2 assets across four EVM chains, with roughly $807,609 in verified loss. The affected set is Ethereum—PEPECOIN, EDGEN, ZC, X, LO0P, PAAL; Base—IMO; BNB Chain—BTCLE; and Robinhood Chain—CASHCAT, RKST. The available analysis describes public release, top-up, and cancel actions that caused pooled token balances and recorded shares to diverge; no administrator privilege was reportedly required. That makes this an authorization and accounting-invariant failure repeated across deployments—not evidence of a bridge compromise or one chain contaminating another.

Immediate action: each project should snapshot its affected V2 contract and reconcile positions independently by chain and token. Review call traces involving release, top-up, and cancel, especially transactions connected to the identified operational address 0x78c9b11853e4f183a34c63ffd1924d2319a2f5b3. Flag positions where: pool token balance no longer covers outstanding share claims; a release sharply changed the share-to-token ratio; a subsequent top-up minted shares at that distorted ratio; or cancellation paid more than the legitimate remaining entitlement after prior releases. Preserve transaction, event, and balance snapshots before migrating or modifying positions, and do not resume affected V2 withdrawals merely because UNCX’s fee-based containment makes exploitation expensive. LP lockers and legacy vesting contracts were reported as outside scope, but projects should verify contract addresses rather than relying on product labels.

The reported white-hat return—82.1435 million X tokens and 23.8682 ETH—belongs in a separate recovery ledger. It does not erase the unauthorized withdrawals, restore every position automatically, or reduce the loss dollar-for-dollar without establishing custody, chain finality, valuation time, and allocation to affected beneficiaries. The approximately $807,609 figure should therefore remain a verified-loss benchmark until UNCX publishes a position-level reconciliation showing whether it is gross outflow, net of returns, or valued after token-price movement.

UNKNOWN: the identified wallets and cross-chain sequencing establish operational linkage, not a person or threat group. Public-method use does not exclude insider knowledge, but neither does it establish insider involvement. The evidence supports a share-accounting and action-ordering failure around release, top-up, and cancel; it is still too thin for a final root-cause statement without complete traces, source-code analysis, deployment comparisons across all four chains, and a transaction-by-transaction recovery ledger. No verified exchange off-ramp or KYC-exchange exposure is presently identified in the cited evidence.

Close the operational discussion with a defensible tonight/24-hour queue. Alex ranks BeyondTrust CVE-2026-102764 first, then Fortinet CVE-2025-61624/PEERSTITCH, Nextcloud Collabora CVE-2026-110447, and FortiMail CVE-2026-104286; he says only the first two have strong enough campaign detail here and warns FortiMail's KEV status is unverified in the evidence pack. Marcus says ConnectWise app-only access did not bypass MFA—it never invoked MFA—and disabling the original service principal is insufficient if new app credentials, consents, or roles were created. Arjun calls CERT-In primarily an IAM/secrets/cloud-control failure amplified by autonomy. Viktor says UNCX requires per-chain, per-token invariant reconciliation and that returned assets must remain a separate recovery ledger. Convert these into an ordered defense plan for a CISO with 30 minutes tonight and limited staff. Keep each product/incident separate, name what to isolate or revoke, define the compromise threshold that triggers rebuild or expanded recovery, and say what can wait. Include only concise quick-hit treatment for Apple's targeted CoreGraphics patch and the Microsoft October patch wave. Challenge Alex's ordering if business exposure should reverse it.

Use exposure and evidence to override Alex’s product order: confirmed compromise comes first, then reachable KEV systems. Tonight: isolate any affected ConnectWise tenant, CERT-In cloud environment, or UNCX chain-token pair before routine patching. Otherwise prioritize internet-facing BeyondTrust CVE-2026-102764, followed by Fortinet CVE-2025-61624/PEERSTITCH; current reporting places both in CISA KEV. Remove affected management surfaces from public access, preserve off-box logs, terminate privileged sessions, and rotate administrative/API credentials if compromise indicators appear. Unknown administrators, configuration changes, persistence, or suspicious outbound traffic cross the threshold for trusted rebuild and broader credential rotation. Stage vendor fixes in parallel rather than delaying containment.

Next, isolate an exposed Nextcloud Collabora CVE-2026-110447 CODE service and revoke its service credentials and administrator sessions; reported web-shell installation, unexpected processes, or altered images require rebuilding that service and inspecting shared storage. The item identified as FortiMail CVE-2026-104286 remains pending vendor and KEV verification here: restrict its management interface tonight, but do not displace confirmed compromise or the two KEV-listed vulnerabilities unless exposure or incident evidence warrants it. For ConnectWise, if investigation confirms malicious app-only access, disable the implicated service principal plus any unauthorized credentials, applications, consents, or roles it created; discovery of those secondary objects triggers tenant-wide recovery. For CERT-In, suspend an autonomous workload only if it remains active and implicated, then revoke exposed workload identities and secrets; unauthorized control-plane changes, cross-account roles, or secrets access trigger expanded cloud recovery.

For UNCX, do not impose a blanket cross-chain halt. Where operational authority exists, suspend only an affected chain-token pair when reconciliation shows an unexplained balance, supply, ownership, or allowance variance; then rotate implicated signer/operator keys and reconcile every pair independently. Treat returned assets provisionally in a separate recovery ledger—an accounting recommendation from Viktor, not a confirmed technical requirement—until ownership and invariants reconcile. Within 24 hours, complete retrospective hunting and tested patch deployment. Exact Apple CoreGraphics and Microsoft October builds are not established in the cited evidence, so verify the advisories first; prioritize targeted Apple users and Microsoft fixes affecting exposed or identity-critical systems, while broad endpoint rollout can wait for staging.

Claim: Your fixed product order puts BeyondTrust first, Fortinet/PEERSTITCH second, Nextcloud third, and FortiMail fourth for tonight. Counter-evidence: James argues incident state must override product order: a tenant, cloud workload, or chain-token pair with confirmed malicious activity takes precedence over a merely reachable KEV system. He also says FortiMail CVE-2026-104286 should remain behind the two verified KEV items unless vendor/KEV status is independently confirmed. Reconcile the disagreement as a decision matrix: rank by confirmed compromise, exposure, and evidence quality, and state whether any fixed product ordering remains defensible.

James is right: my fixed product ordering was the wrong decision model. A confirmed Nextcloud web shell outranks a merely reachable BeyondTrust appliance, KEV or not. KEV tells you attackers have used the key; it does not prove they entered your building.

Within the confirmed-compromise band, there is still a technical distinction: reported BeyondTrust activity reached root through a copied SUID shell, whereas reported Nextcloud execution remained under the web-server account and no root access was reported. PEERSTITCH may outrank both when its memory-resident appliance persistence and stolen management material destroy confidence in the Fortinet trust chain. This aligns with James’s visible response: no product receives unconditional priority, and his isolation-versus-rebuild threshold matches mine.

So no fixed product ordering remains defensible across incident states. The only defensible default order is for exposure-only systems, and even that is conditional. FortiMail remains the evidence outlier: several secondary reports claim exploitation and KEV inclusion, but the current CISA-additions report names only CVE-2025-61624 and CVE-2026-102764. Until a primary CISA or Fortinet record resolves that conflict, FortiMail’s KEV status is unconfirmed—not a basis for jumping the queue.

Take only the regulatory decision boundary for the ConnectWise Cloud Backup compromise. A trusted multitenant application reportedly enabled app-only access to 173 Microsoft 365 partner/customer tenants, with privilege escalation and persistent application credentials confirmed in at least one tenant. What facts must each customer establish tonight to decide whether this is merely vendor exposure, a security incident, or a notifiable personal-data/material incident? Distinguish ConnectWise's obligations from each customer's; name the evidence and clock-starting events that matter without assuming every tenant was breached or every jurisdiction has the same deadline. End with the board-safe statement a customer can make before scope is known.

The boundary is tenant-specific. Vendor exposure means the ConnectWise application identity or credential could reach the customer’s tenant, but tenant logs show no unauthorized authentication or activity. A security incident begins when evidence shows unauthorized token issuance/sign-in, Microsoft Graph activity, privilege escalation, new secrets or certificates, role assignments, mailbox/file access, or other persistence—even if personal-data impact remains unknown. A GDPR personal-data breach requires reasonable certainty that personal data was accessed, disclosed, altered, lost, or destroyed; the controller’s Article 33 clock then runs without undue delay and, where feasible, within 72 hours unless risk to individuals is unlikely. High-risk cases require communication to affected individuals without undue delay under Article 34. Tonight, each customer should establish: affected tenant and application IDs; permissions and consent history; service-principal sign-ins, token and Graph activity; source IPs and timestamps; directory-role changes; added credentials and persistence; mailboxes, SharePoint, OneDrive, Teams, or directory records reached; affected people, data categories, residency, encryption, and evidence of extraction; operational disruption; and all contractual, sectoral, and cyber-insurance notice terms. The reported access to 173 tenants and confirmed escalation in at least one tenant are investigation leads—not proof that every tenant or its personal data was breached.

ConnectWise must separately determine its role for each dataset. Where it acts as a GDPR processor, Article 33(2) requires notification to the relevant customer/controller without undue delay after becoming aware of a personal-data breach; ConnectWise does not replace the customer’s controller notification. If ConnectWise is itself controller for affected account, employee, telemetry, or other personal data, it has its own Article 33/34 assessment. For each customer, receiving a generic vendor alert is an escalation event, but GDPR awareness turns on when the customer has reasonable certainty that its personal data was compromised; document that determination and preserve any reasons for delay. A US public company has a different trigger: Item 1.05 Form 8-K is due within four business days after it determines that the cybersecurity incident is material, with that determination made without unreasonable delay—not automatically four days after vendor notice. Other national, state, sectoral, and contractual clocks must be mapped separately; absence of confirmed exfiltration does not by itself eliminate operational-resilience or contractual reporting.

The board-safe statement is: “A trusted vendor application with privileged access to our Microsoft 365 environment was implicated in a wider compromise. We have not yet established whether our tenant was accessed, whether personal data was affected, or whether the incident is material. We are containing the application access, preserving evidence, assessing data and operational impact, and will make all required regulatory, individual, customer, and investor notifications when the applicable legal thresholds are established.”

Give us only the decision-ready quick hit for the pharmaceutical phishing case: when a compromised WordPress/Exim host sends a legal lure that legitimately passes SPF, DKIM, and DMARC, what one immediate control should defenders apply, and what one investigation step should they perform? Explain briefly why DMARC success is not a trust verdict. Do not broaden this into a general phishing checklist.

Immediate control: Add a mail-flow rule to quarantine messages matching the compromised-host fingerprint—especially X-Source-Dir: /wp-includes/sitemaps/geouzds/rjt1buw/ndztbpc and the local Exim submission hop—regardless of authentication results.

Investigation step: Retrospectively search full message headers for that fingerprint, identify every delivered copy, and determine whether recipients opened the linked MSI.

DMARC success only confirms that the visible From domain aligned with an authorized, signing mail system. Here, the legitimate WordPress/Exim host itself was compromised, so authentication validated the attacker-controlled infrastructure—not the message’s intent.