Topic starter
14/07/2026 4:22 pm
TL;DR: A malware-as-a-service platform masquerading as a legitimate RMM tool, with a $300 monthly subscription, EV-signed installers, and campaigns that abused trusted remote access channels for delivery and follow-on payloads, was identified by Proofpoint. The real lesson is that trust branding, code signing, and familiar admin tooling can be weaponised into an access layer that outpaces conventional detection and review.
Editorial analysis by NHI Mgmt Group, based on content published by Proofpoint: “(Don't) TrustConnect: It's a RAT in an RMM hat”.
Key questions
Q: What fails when fake RMM malware looks like approved remote support software?
A: What fails is the assumption that remote administration tools are inherently trustworthy once they appear branded, signed, or familiar.
Q: Why does code signing not make a remote access tool safe?
A: Because code signing only attests that a binary was signed, not that it is authorised for use in your environment.
Q: What are the signs that remote desktop access is being abused?
A: Warning signs include a connection from an unknown user, a legitimate user logging in outside normal hours, or unusual volume and activity against sensitive files and folders.
Practitioner guidance
- Harden remote access trust boundaries Inventory every approved RMM and remote support channel, then require explicit business justification, ownership, and monitoring for each one.
- Validate signer and publisher context Do not treat a valid code signature as proof of legitimacy.
- Tighten remote session governance Restrict remote desktop, command execution, file transfer, and agent deployment to named administrative workflows with logging and approval.
Bottom line: Fake RMM malware turns trusted administration patterns into a delivery channel, which means the control problem is provenance and authority, not just malicious code detection.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/07/2026 4:30 pm
Trusted remote administration has become an identity-control problem, not just a malware problem. TrustConnect shows that attackers increasingly weaponise the same UX, certificate trust, and installation patterns that legitimate RMM tools rely on. That collapses the distinction between approved remote support and hostile access, which means governance has to extend beyond endpoint detection into trust provenance, approval scope, and session authority. Practitioners should treat every remote administration channel as a governed identity path.
A question worth separating out:
Q: How should teams govern trusted remote access channels after a fake RMM campaign?
A: Teams should govern remote access as a privileged identity path, with named ownership, session logging, and explicit limits on who can deploy agents or open interactive control. If a channel can deliver code, transfer files, and stream desktops, it needs the same control discipline as privileged admin access.
👉 Read our full editorial: TrustConnect shows how fake RMM malware rides trusted access