Remote access software: the tool is legitimate, and that is precisely the problem

CISA, the NSA, the FBI, MS-ISAC and Israel’s INCD jointly published a Guide to Securing Remote Access Software. It is marked TLP:CLEAR, so freely distributable, and it is the clearest public account of why the tools your integrators use to reach your plant are also the tools attackers prefer.

It came out in June 2023. That matters in one respect only: the named product lists have aged. The mechanism has not, and the incidents of the following two years have kept confirming it.

Why attackers choose your own tools

The guide is precise here, and its reasoning is worth following because it explains why your existing defences stay quiet.

First, these tools do not trigger security products. Remote access software has legitimate uses, so it blends in. Commercial remote monitoring and management (RMM) agents are signed with valid code-signing certificates from trusted authorities, and antivirus or endpoint detection and response (EDR) has no reason to find them suspicious. The guide also points to something most organisations have done to themselves: RMM install paths are often excluded from EDR inspection, because the agent and the endpoint tool interfere with each other. An exclusion made for operational reasons becomes the blind spot.

Second, the attacker has nothing to develop. There is no need for a remote access trojan when your own tool already does what a RAT does and is already deployed.

Third, many of these tools ship as self-contained portable executables. They launch in the user’s context without installation, which gets round both administrator privilege requirements and software allow-listing. An organisation can be blocking the installer and still be running the program.

Fourth, many RMM agents use end-to-end encryption, so files a firewall would normally detect and block travel inside the tunnel.

And it scales. Compromise a managed service provider and you reach every customer at once. The guide says plainly that small and mid-sized organisations relying on MSPs for IT, OT and ICS support are exposed to service-provider supply chain compromise for that reason.

This is living off the land applied to remote access. Nothing malicious is brought in; what is already trusted gets used.

The chain, in ATT&CK terms

The guide maps the behaviour to MITRE ATT&CK. The sequence is worth knowing, because it is what detection has to look for:

• Initial access: T1133 External Remote Services (exploiting externally facing services such as VPNs), T1078 Valid Accounts (legitimate compromised credentials), T1199 Trusted Relationship (through a third party), T1195 Supply Chain Compromise (modified versions of legitimate RMM), T1566 Phishing (leading victims to install RMM themselves).
• Execution: T1059.001 PowerShell, used to deploy the RMM agent silently.
• Defense evasion: T1036 Masquerading. The guide cites a real example, a NetSupport binary renamed ctfmon.exe, a legitimate Windows process name.
• Discovery and lateral movement: T1018, T1563 Remote Service Session Hijacking, T1021, T1210.
• Command and control: T1219 Remote Access Software. The tool is the C2 channel.

Put together: the adversary comes in through a remote path, uses valid credentials, deploys a signed tool, renames it, moves laterally, and keeps the same tool as its command channel. At no point is there a file for an antivirus to catch.

What this looks like on an industrial site

The guide is written for general IT and for MSPs. Translated to a plant it gets uncomfortable, because there the remote access tool has three properties it rarely has in an office.

Nobody owns it. The machine builder or the integrator installed it during commissioning so that their support team could connect. IT did not deploy it and often does not know it exists. The plant knows, but treats it as part of the machine. It is in neither inventory.

It is permanent. A support contract justified it, so it stays for the life of the equipment, fifteen to twenty-five years. It is rarely reviewed, rarely re-authenticated and almost never limited in time.

It may not cross your firewall at all. The worst case is the tool that reaches the machine through a cellular modem inside the cabinet, usually zip-tied to the DIN rail next to the PLC. It does not defeat your perimeter. It never passes through it.

One of the best-known intrusions on an industrial operator turned on this class of access. At Colonial Pipeline in May 2021, according to its chief executive’s testimony to the US Senate, the attackers came in through a legacy VPN account that was no longer used but was still active. The pattern repeats in almost every assessment we run: the account of a supplier who finished the project three years ago.

The recommendations worth acting on

The guide is long. These are the items that change outcomes on an industrial site, roughly in the order I would tackle them.

Inventory what is actually installed. The guide’s first host-based recommendation is to audit remote access software and configurations across the network, to know what is in use and what is authorised. On a plant this means walking the line with the maintenance team rather than querying a domain. Expect to find tools nobody can name.

Decide on one approved path, and block the rest. Authorised remote access solutions should only be used from inside your network over an approved path (VPN or virtual desktop), and both inbound and outbound connections on common RMM ports and protocols should be blocked at the perimeter. Outbound matters as much as inbound: an agent that calls out sets up the same channel as one that is called in.

Do not let it hide in ordinary web traffic. The guide recommends that remote access software run from local instances in the environment and avoid HTTPS port 443. Traffic on 443 looks like browsing, and you lose the ability to police the channel at the network layer.

Keep the logs out of the tool’s reach. One recommendation deserves to be applied everywhere, not only by MSP customers: direct access to log servers, and the ability to delete or alter logs, must stay out of reach of RMM tools. If the supplier’s tool can edit the record of what the supplier’s tool did, there is no record.

MFA, by priority. Enable just-in-time access and multi-factor authentication according to risk. On a plant, start with every path that reaches in from outside, not with the control room HMI, where it is often inappropriate and sometimes unsafe.

Reduced privilege by default. The guide recommends configuring RMM tools with reduced privilege for common uses, such as read-only monitoring. Most vendor remote support does not need write access to a controller most of the time, and the sessions that do should be the watched exception.

Know what normal looks like. The detection advice starts with a point that applies to every control in this article: defenders must know the software’s normal behaviour well to recognise abnormal behaviour. Without that baseline, an RMM session at 02:00 from an unfamiliar address looks exactly like scheduled maintenance.

The contract clauses, and their NIS2 consequence

The section aimed at MSP and SaaS customers reads, for an industrial site, like a list of clauses for the next integration or support contract:

• How and when the provider notifies you of an incident affecting your environment. Under NIS2 supply chain security is an explicit obligation, and your own 24-hour early-warning clock can only start once your supplier has told you.
• Visibility of the provider’s activity (their presence, actions and connections to your network) written into the contract, with their accounts monitored and audited.
• A clear statement of what is and is not in scope, including incident response and recovery. The guide asks providers to explain plainly what the customer is buying and what it is not.

For anyone who is a provider, two rules from the guide travel well: do not reuse administrative credentials across customers, and treat every account with access to a customer environment as privileged, with MFA.

One honest caveat about the lists

The guide names products, both general tools and a list of remote access software geared toward OT networks. Treat those lists as illustrative and dated. One entry, PCAnywhere, has been end-of-life for years, which is a useful reminder in itself: the guide separately advises against end-of-life software, and remote access is the worst place to run it.

The method holds: inventory what is present, allow one path, block the others in both directions, keep the logs beyond the tool’s reach, and know what normal looks like.

The software you trusted enough to exclude from inspection is the software an adversary would choose. Start the inventory there.

References

• CISA, NSA, FBI, MS-ISAC and INCD, Guide to Securing Remote Access Software, June 2023, TLP:CLEAR: cisa.gov
• MITRE ATT&CK, T1219 Remote Access Software: attack.mitre.org