Mitigating the trendy threat of cyber criminals LOTL (living off the land)
If there’s one significant decade-long trend that happened and is here to stay, it is the ability to work remotely and screen-share. It is for this reason that we have such a plethora of powerful tools to remotely share screens. Many expanded their capabilities to include remote control and that’s where the criminals really started to notice.
By end of the year, I’d be surprised if research doesn’t highlight what a large percentage of threats’ initial vector was via legitimate remote access tools. No fancy multi-stage infection was required for a C2 channel. LoTL is faster, better, cheaper (for the criminal).
The state of exploitation is so horrific already that CISA, earlier this year, issued a Joint Guidance: Identifying and Mitigating Living Off the Land Techniques, with a strong focus on Remote Access Tools.
This blog article is written specifically for the purpose of offering systems administrators a comprehensive list of remote access tools and how they can be blocked. Most organizations will want their own official choice of remote access tool to function, but disallow all others. That’s what we’re aiming for here as well.
To start with, here’s a list of products that have been researched to varying degrees and classified into one of two tables, ones that can knowingly be blocked by DNS&DTTS (first table below) and ones that are self-hosted and for which Zero Trust connectivity is required in order to block unknown/untagged FQDNs+DTTS:
Blockable by DNS black-holing (DTTS also sometimes required):
* Remote tool persistence is reliably blocked by DTTS®. Some tools are purposefully designed to work so that even when DNS failures occur, sysadmin remote access continues to function. This is by design for good purposes, but can also be hijacked by malicious actors.
RMM Remote Access Tools using self-hosted models, apply whitelabels or other existing vendors
The following tools are included for reference, even though there isn’t a given set of domains or IPs where such tools are hosted. For your organization to be protected from such hosted services, Zero Trust connectivity offers the protection you need.
| Remote Tool | Notes |
|---|---|
| Atera | Uses Anydesk as preferred remote access tool |
| Bomgar | Self-hosted and not generally a threat as it’s economically usually out of reach by most threat actors |
| Radmin | Free trial with full functionality, hence it is easy for an attacker to use in a campaign |
| RMS (Remote Manipulator System) | Only ever seen in use for malicious purposes |
| Remcos* | Self-hosted, free version, reported used by attackers even integrates with Telegram bot |
| RemoteUtilities | Never observed for malicious use, usually licensed and self-hosted for internal, enterprise use only |
| RPort | Self-hosted |
| RSAT | No longer available to download |
| Rustdesk | “Open source alternative to TeamViewer” and, therefore self-hosted for the controller |
| ScreenConnect | Listed above also for ConnectWise-hosted versions, but there’s also a self-hosted version available |
| SimpleHelp | |
| Sorrilus | |
| SuperOps | This vendor uses Splashtop |
| Syncro | This vendor uses Splashtop |
| TacticalRMM | Self-hosted tool |
| Wazuh | Open-source SIEM endpoint agent is open for abuse |
| ZeroTier | Overlay network that can facilitate P2P connections, but not a remote access tool in itself |
Subscribe to our blocklist
If you’re running adam:ONE, log into your dashboard and you can subscribe to our blocklist here.
Simply enable it on all policies where you wish to block these known remote access tools.
For DTTS to be enabled, a plan that includes the feature will be required.
Enabling resources actually in use in your enterprise
If you blanket-block the above known remote access tools and yet you wish to use one legitimately by policy, a Forwarding Rule can be used as an exemption from a blocklist.
For example, the ADAMnetworks team uses a Bomgar appliance, and even though it isn’t in the blocklist above as it’s self-hosted, I will use it as an example to demonstrate how it can be exempted even if it were on a blocklist:
-
Create a resolver to use if you don’t already have one, we suggest Quad9:
-
Create a forwarding rule if you don’t already have one, call it “Exempt from all filtering”:
-
Enable the rule on all policies where the rule should be applied:
Notes
Some tools are listed twice if a version of the tool fits into more than one category as different versions of the tool behave differently.
In each category, tools are listed in alphabetical order, but there’s a clear delineation between tools favoured by bad guys vs good guys.
Tools that work with direct connections did not make it on the list, e.g. MobaXterm, Apple Remote Desktop, VNC, Microsoft Remote Desktop, NetSupport, RemoteRipple etc. For such tools to be exploited, the attacker would need additional resources such as port-forwarding, or adding an overlay network and Windows firewall modification, etc.
Online meeting tools allowing for remote desktop are not listed, but we must be aware that combined with enhanced social engineering, could also be used for remote control, such as these three major ones:
If any of the details are out-of-date in the future, we would welcome any feedback on our support email from users and sysadmins alike with updates that may be required.