Remote access software exists so that one person can control another computer. That is also what an intruder wants. MITRE ATT&CK tracks the abuse of legitimate remote tools as T1219, Remote Access Tools, in the Command and Control tactic. It applies to Linux, macOS and Windows, and has three sub-techniques: IDE Tunneling, Remote Desktop Software and Remote Access Hardware.
How attackers use it
MITRE describes adversaries using legitimate remote access tools to set up an interactive command and control channel inside a network. These tools create a session between two trusted hosts through a graphical interface, a command line, a protocol tunnel built into development or management software, or hardware level access such as KVM over IP.
Two flavors are named. Desktop support software, usually graphical, and remote management software, typically command line. Either way the session inherits the user or software permissions, as if the operator were a local user. The software is commonly used for troubleshooting, software installation and system management, so it is often permitted.
MITRE adds that adversaries may similarly abuse response features in EDR and other defensive tools that enable remote access.
Other points from the page:
- The tools may be installed post compromise as an alternate communications channel for redundant access, or to open an interactive remote desktop session.
- They may also be a malware component that makes a reverse connection to an adversary controlled system.
- Installation of many tools includes persistence, such as the installer creating a Windows service.
- Remote access features may exist inside software you already run, for example Chrome's Remote Desktop.
Why it works
The program is real. It may be signed. Its traffic goes to a vendor's service on a normal port, and your users may already use the same product. If the question your controls ask is only whether the software is known, the answer is yes.
The better question is whether this software is approved, on this machine, started by this person, for this purpose.
How to detect it
MITRE's tool agnostic strategy describes a behavior chain:
- Initial execution of a remote control or assist agent or GUI under a user context.
- Persistence through a service or autorun.
- A long lived outbound connection or tunnel to external infrastructure.
- Interactive control signals, such as shell or file manager child processes spawned by the remote tool.
Linux and macOS versions swap in their own persistence: a systemd service on Linux, and a LaunchAgent or Daemon on macOS, with interactive children such as osascript, sh or curl.
What to collect:
- Process creation and service installation events. On Windows that includes service creation (Security event 4697, or System event 7045).
- Network connections and DNS queries to the domains used by remote access products.
- Software inventory, so you can compare what is installed with what is approved.
- Child processes of remote access agents.
Tuning
Write down the remote tools your IT team sanctions. Anything else is a finding. Pay special attention to tools that appear on a machine without a matching ticket or deployment record, and to new services created shortly after a user session starts.
How to reduce the risk
MITRE lists five mitigations.
- Execution prevention. Use application control to stop installation and use of unapproved software that can be used for remote access.
- Filter network traffic. Configure firewalls, application firewalls and proxies to limit outgoing traffic to the sites and services used by remote access software.
- Limit hardware installation. Block IP based KVM devices on the network if they are not required.
- Network intrusion prevention. Network signatures may stop traffic to remote access services.
- Disable or remove the feature or program. Turn off unnecessary remote connection functionality, including unapproved installs and built-in features of supported applications.
A practical order
- Decide which single remote support tool the company uses and write it down.
- Block the domains and installers of the rest at the proxy and in application control.
- Alert on any other remote access product that starts anywhere.
- Review the built-in remote features of the browsers and collaboration tools you allow.
Check your own environment
- Do you have a list of approved remote access tools?
- Can your proxy tell you which devices contacted remote support services in the last 30 days?
- Do you record new Windows service installs?
- Can IP KVM devices be plugged in without anyone noticing?
This read-only PowerShell command lists installed services on Windows with their paths, which helps you spot remote tool agents that you do not recognize:
Get-CimInstance Win32_Service | Select-Object Name, DisplayName, State, PathName
On Linux, this read-only command lists active systemd services:
systemctl list-units --type=service --state=running
What good looks like
In a well run environment, there is one sanctioned remote support product, and every use of it ties back to a ticket. Other remote access software cannot install or reach its relay services. Built in remote features are off unless needed. IP KVM devices are blocked. And when something outside that pattern starts, an alert fires with the process tree, the persistence it created and the destination it connected to.
Quick check
Why is a legitimate remote tool hard to flag by name alone?
It is real, often signed, and possibly used by your own IT team, so only context such as approval, host and timing separates misuse.
What does MITRE suggest to limit traffic?
Configure firewalls, application firewalls and proxies to limit outgoing traffic to the sites and services that remote access software uses.
Name the three sub-techniques.
IDE Tunneling, Remote Desktop Software and Remote Access Hardware.
Sources
- MITRE ATT&CK, T1219: https://attack.mitre.org/techniques/T1219
