RMM partner diligence

RMM partners
ScreenConnect
Partner oversight
Client-side control

006 / 2026

Helpdesk remote access sits inside the trust boundary. The moment an MSP technician, a “Geek Squad” callback, or a Quick Assist session can reach a principal endpoint, the control question is no longer whether the tool is branded. It is who can transfer and run code on that host — under whose standard, at which version, with what confirmation.

That is control before coverage.

What ConnectWise and Huntress actually say

Keep the vendor bulletin and the threat reporting in separate lanes.

On 8 September 2026, ConnectWise published a ScreenConnect security bulletin for CVE-2026-84869. ConnectWise classified the issue under CWE-862 (Missing Authorization) and CWE-269 (Improper Privilege Management), with a CVSS base score of 9.9. Severity: Important. Priority: 1 High. The condition is client-side: in certain circumstances, files may be transferred and executed through an active remote session without authorization or Host confirmation. ConnectWise stated ScreenConnect servers are not impacted. Versions prior to 26.6.5 are impacted. The fix is ScreenConnect 26.6.5. After upgrade, ConnectWise instructs partners to reinstall host clients and update access agents. Temporary mitigation, if the update cannot ship immediately: deselect the TransferFiles permission on all roles under Administration > Security > Roles. That mitigation is not a substitute for the patch.

Separately, Huntress documented rogue ScreenConnect clients across unrelated organizations. Many of those cases began with social engineering — Quick Assist abuse, phishing that led to a ScreenConnect client MSI, or Geek Squad refund bait that talked a user into running a rogue client. Huntress observed a four-stage VBScript chain (1.vbs through 4.vbs) launched via wscript.exe, with persistence through a WindowsServiceHost User Run key pointing to WindowsServiceHost.vbs in AppData. Some hosts also received secondary RMM tools such as UltraViewer.

Huntress’s harder finding: modified ScreenConnect clients can automatically push that same VBS chain onto newly connected Hosts — worm-like behaviour across sessions. In ScreenConnect audit logs, RunFiles / RanFiles entries for those scripts executed from Process: Guest should be treated as immediately suspicious. Huntress recommended that compromised hosts be reimaged from known-good media.

Do not collapse those layers. ConnectWise describes a client authorization / privilege-management flaw and a patch path. Huntress describes social-engineering entry, rogue clients, and modified clients that propagate payloads. Not every ScreenConnect install is backdoored. Social engineering started many of the Huntress cases. This Brief invents no Alberta MSP victim names and no Canadian victim counts.

Why this matters for Alberta principals and Canadian mid-market

MSP and RMM tools are ordinary infrastructure for Alberta clinics, family offices, professional services firms, and executive laptops that live half the week on hotel Wi-Fi. Remote support is not exotic. It is how tickets get closed. That convenience puts a third-party remote-access stack inside the same trust boundary as finance workflows, patient or client records, and the devices principals carry.

The transferable lesson is partner diligence, not product panic. Who owns the remote-access standard on principal endpoints? Which RMM products are authorized? Which versions are live? Who can approve a file-transfer / run action during a session? If those answers live only in the MSP’s marketing slide, the client is renting hope.

Adjacent risk is operational, not theatrical. A compromised helpdesk path can become a path to payment-destination fraud, credential theft, or quiet persistence on an executive machine. Dual-channel verification for unexpected “IT is calling” outreach belongs next to the same discipline used for payment-authority changes. Coverage tools do not replace that ownership.

The control questions

Answer these in writing before the next remote session on a principal machine.

Who is authorized to run remote-access software against executive, finance, and clinical endpoints — named MSP, named roles, named tools?

What ScreenConnect (or equivalent RMM) version is actually deployed on those hosts, and has TransferFiles been reviewed against ConnectWise’s temporary mitigation guidance until 26.6.5 is confirmed everywhere that matters?

After any upgrade to 26.6.5, were host clients reinstalled and access agents updated as ConnectWise requires — or did the server patch land while old clients stayed in the field?

Who on the client side owns the MSP remote-access standard the same way finance owns payment-destination changes?

If audit logs show RunFiles / RanFiles of unexpected scripts from Process: Guest, who gets the page, and what is the isolation / reimage standard?

Forged-CS’s lane here is advisory: map the remote-access trust boundary around principals and operators, diligence MSP and RMM partners, and set the oversight standard from the client’s side of the table. We do not sell RMM. We do not run a 24/7 SOC or an MDR stack. We do not operate as an MSP. Where regulated investigative or technical field work is required under Alberta or other applicable law, that work belongs with vetted licensed partners. Oversight stays with the client.

Client-side diligence that actually moves risk

Inventory first. List every RMM, remote-support, and “quick help” path that can reach principal and finance endpoints — ScreenConnect, competing RMM products, built-in tools like Quick Assist, and any vendor “temporary access” habit. You cannot oversee what you have not mapped.

Confirm version and patch posture in writing from the MSP. For ScreenConnect, require confirmation of 26.6.5 (or later), plus evidence that host clients were reinstalled and access agents updated after the server-side upgrade. Until that is done, ask whether TransferFiles remains enabled on any role that can touch your sessions — and treat ConnectWise’s deselect guidance as temporary exposure reduction, not closure.

Treat unexpected remote-support outreach as dual-channel verification territory. A cold call claiming to be IT, Geek Squad, Microsoft, or your MSP is a control event until proven otherwise. Verify through a known-good number or ticket channel before anyone opens Quick Assist or runs an MSI. The same discipline that protects payment authority protects remote-access authority.

Raise the audit-log standard with the partner. Ask how they would detect RunFiles / RanFiles of guest-executed scripts, how fast they would notify you, and what their isolation playbook looks like. Prefer partners who can answer in concrete process language over partners who answer in brand adjectives.

Post-incident hygiene is a control. If a host may have been reached by a rogue or modified RMM client, preserve timelines and logs, isolate, and treat Huntress’s reimage-from-known-good-media guidance as the serious option — not a soft reboot and a hope cycle. Secondary RMM installs (UltraViewer and peers) deserve the same scrutiny as the first tool.

Separate corporate from household surfaces where executives blur them. A principal who accepts “IT help” on a personal machine that also holds work mail and banking creates a single failure surface. Map that surface. Reduce unnecessary acceptance of cold remote-support requests at home the same way you would at the office.

What this Brief is not

This is not a claim that every ScreenConnect deployment is compromised. It is not a Canadian victim census. It is not a pitch that Forged-CS sells RMM, SOC, MDR, or managed helpdesk. It is decision-ready diligence for Alberta and Canadian principals who want third-party remote access under client-side control — with licensed partners where field work requires it, and with oversight kept where it belongs.

Control before coverage

If the next helpdesk session can move and run files on a principal host without a clear authorization standard, you are already negotiating from behind. Inventory the RMM paths. Confirm versions and TransferFiles posture. Own the dual-channel rule for “IT calling.” Decide the reimage standard before you need it.

Then decide what tools or partners you actually need.

Forged-CS is the client-side control layer — risk architecture and partner oversight, not more coverage.

— Hassan Sukhera | Forged-CS | forged-cs.com

FAQs

Is every ScreenConnect install a threat?

No. ConnectWise documented a client-side authorization flaw with a defined patch (26.6.5). Huntress tracked social-engineering entry and modified clients in specific incidents. Diligence the partner, the version, and the permissions — do not treat the product name alone as proof of compromise.

What should an Alberta principal ask their MSP first?

Confirm whether ScreenConnect (or equivalent RMM) touches executive endpoints; require version evidence for 26.6.5+; ask whether TransferFiles is enabled on roles that can reach those sessions; and require a written process for dual-channel verification of unexpected remote-support requests.

What audit-log cue did Huntress highlight?

RunFiles or RanFiles entries showing suspect scripts (such as the four-stage VBS chain) executed from Process: Guest. Treat that as immediate suspicion and escalate per your incident standard.

Does Forged-CS replace an MSP or run RMM?

No. Forged-CS provides advisory risk architecture and partner oversight. We do not sell RMM, do not operate as an MSP, and do not run SOC/MDR. Regulated field work, where required, is scoped through vetted licensed partners under applicable law.