• Remote system management/desktop access tools such as AnyDesk and TeamViewer have grown in popularity since 2020. While there are many legitimate uses for this software, adversaries are also finding ways to use them for command and control in their campaigns.
  • There is no easy way to effectively block all unauthorized remote management tools, but security can be greatly improved through a combination of policy and technical controls.
  • Early warning alerts can be configured to alert defenders to remote management software activity that may have circumvented the technical controls.

Update (June 20, 2024): Added sophisticated Splunk detections for unwanted remote access/management software. Read more in the “SIEM Alerts - Splunk” section below.

The remote management/access software problem

Since 2020, the use of remote system management/access tools such as AnyDesk and TeamViewer has exploded in popularity due to forced work-from-home during the COVID-19 pandemic.

Whether used by an IT help desk technician to fix a user’s remote system or by co-workers for collaboration, these tools play an essential role in most corporations’ digital functions. However, this convenience comes at a cost. These tools introduce the ability for an adversary to potentially take full remote control of a system, are easy to download and install, and can be very difficult to detect since they are considered legitimate software. 

Further complicating the task of recognizing the malicious use of these tools, many organizations struggle to combat “shadow IT” in which individual users or overly proactive IT personnel might install unauthorized remote management tools to accomplish a benign goal.

Cisco Talos Incident Response (Talos IR) is seeing adversaries capitalize on this opportunity in the wild. We recently noted in our Quarterly Trends report for the third quarter of 2023, “AnyDesk was observed in all ransomware and pre-ransomware engagements [. . .], underscoring its role in ransomware affiliates' attack chains.”

While AnyDesk is a legitimate application, it highlights the tremendous value that can be gained through a security program that intentionally focuses on preventing unauthorized use of these tools. Talos is referencing AnyDesk for the purposes of this blog post, but any remote management tool is at risk of these exploits. There are several policy changes, technical countermeasures and security alerts that admins and defenders can use to ensure that AnyDesk, and similar pieces of software, are only used for legitimate purposes when deployed.

Policy change suggestion: Pick one approved remote management tool

Adopting one, or at most two, approved remote management solutions will allow the organization to thoroughly test and deploy in the most secure possible configuration.

If possible, integration with other organizational technology such as Active Directory or multi-factor authentication (MFA) will provide additional layers of protection and verification. Tying the approved remote management solutions into these already structured security solutions can make it easier to build “early warning” detections and alerts around unauthorized connectivity and use.

Once a solution is approved and championed for the organization, other remote management/access tools should be explicitly banned by policy. Ideally, this should be accompanied by a software inventory audit and published guidance on approved/non-approved software for the organization. Training and consistent enforcement of this policy will help reduce the “shadow IT” noise in the environment and leave network defenders with more time to investigate true anomalies.

Technical controls

While very worthwhile, preventing unauthorized use of these tools is not simple. First, the scores of commercially available remote access tools make it difficult to address every option an adversary might use. Many of those tools are frequently updated, meaning that blocking the executables by their hash value is not as effective. 

Adversaries also commonly rename the executables, meaning that filename blocks aren’t going to be helpful, either. 

Many popular solutions operate over common ports and protocols, such as ports 80 and 443, making them difficult to block at the firewall, and remote access tool creators often decline to publish their central server IP addresses due to frequently changing resolutions, which limits the effectiveness of static IP address blocks. A combination of approaches and techniques is necessary to limit the opportunity for an adversary to use remote access/management tools in any given environment.

DNS security controls

One of the most effective methods for detecting, and sometimes blocking, the activities of unauthorized remote management/access software, is by auditing and blocking DNS queries associated with these tools.

If your organization uses Cisco Umbrella for DNS security, it’s fairly easy to review and block DNS queries related to unauthorized traffic.

To review what might already be on your network, log into the Umbrella console and view “Reporting > App Discovery > Unreviewed Apps,” filtered by the “Collaboration” and “IT Services Management” categories, this is an excellent starting point to identify unexpected remote access software.

Simply clicking “Block this app” gives the administrator the ability to block future DNS requests associated with any particular result. If you prefer to take an even more proactive approach, going to “Policies > Policy Components > Application Settings” allows you to search all applications currently categorized by Umbrella, whether they have been seen on your network or not, and block them by policy. Again, the “Collaboration” and “IT Services Management” categories should be the areas of focus for policy review.

As with all of these technical controls, there are a few limitations. The first major caveat is that this only works if the DNS queries are evaluated by your security stack. In the case of DNS traffic from a home user’s system not traveling over the corporate network, the activity would be invisible. The second major caveat is that some remote management software has direct peer-to-peer capabilities, meaning the software might not send a DNS query to an easily identifiable domain when initiating a connection. 

Firewall controls

While less scalable and reliable, basic IP address blocking can be beneficial for preventing unauthorized remote software connections. Some vendors list static IP addresses for their central servers on their support sites that can be leveraged to control this access. However, many vendor IP addresses change periodically, making the task a bit challenging.

Another potentially fruitful approach to firewall traffic blocking is by port number. For example, TeamViewer prefers to use port 5938, although it can fall back on the practically unblockable port 443. While blocking port 5938 would not stop the connection, a properly configured alert would provide defenders with an early warning that TeamViewer was trying to connect out.

Some firewalls also provide additional functionality around session content, similar to Umbrella’s capabilities. Firewalls such as Cisco’s Meraki provide an allow/block URL listing that can be configured to prevent connectivity to unapproved remote management software sites. Cisco Meraki can provide content filtering options that may be helpful in blocking remote management/access sites.

Administrators should consider that firewall controls to combat unauthorized remote software management connections can have unintended consequences and should be heavily tested and piloted prior to implementation.

Verify that IP addresses are dedicated to that application prior to blocking in order to avoid blocking Content Delivery Network (CDN) nodes or other cloud computing shared resources. 

Finally, network segmentation or micro-segmentation can be useful in blocking unauthorized remote management software usage. For instance, categorizing and organizing server resources separate from workstation resources can allow for more tailored options around blocking all unnecessary traffic at the firewall, include that which may be associated with remote management tools. Some organizations already do this well by integrating with group policy configurations.

Host-based controls

Windows Defender Application Control (WDAC) and AppLocker

Of all the controls discussed in this post, WDAC and AppLocker are the only ones that can offer almost 100 percent protection against unauthorized remote management/access software execution.

In their most secure configuration, which allows only pre-approved software to run, users or adversaries can't run unexpected executables. However, this comes at a cost, as the approved software baseline maintenance level of effort can be high, and the user experience can be very limited if they are not allowed to install applications as needed.

WDAC and AppLocker offer considerable flexibility in their policies, so some organizations choose to only lock down their critical servers, such as domain controllers, which leaves user system policies more flexible. This approach has benefits far beyond simply blocking remote access/management software, as it will stop most malware from executing, as well.

Keep in mind that, while WDAC is currently more difficult to configure, it has more advanced capabilities and Microsoft is positioning it as the replacement for AppLocker. At the moment, AppLocker is receiving security updates, but no new feature updates.

Registry filename blocks

It is possible to block remote management/access software execution by filename via a registry “DisallowRun” key. However, Talos IR does not recommend this approach, except as a containment measure during incident response, since it is not scalable as a preventative measure and is trivially easy to bypass by renaming the executable or modifying the registry. 

EDR blocks

Almost every modern EDR can block file hashes, which gives defenders the capability to block the hashes associated with remote management/access software installers and/or installed executables. However, similarly to the filename GPO blocks, this is not scalable or reliable as a proactive measure, since every new version of every software distribution will have a new hash value. This measure should be restricted to containment during incident response only. 

Some EDR solutions offer methods to block vulnerable or unauthorized software, albeit with significant caveats regarding the limitations of those capabilities. The authors of this article have not tested those capabilities but note them here for the sake of completeness.

Host-based firewalls

The recommendations for host-based firewall rules are much the same as standalone firewalls, covered above. These can be useful where administrators expect users to roam outside of the boundary of the corporate network, such as home workers off the corporate VPN or using a split-tunnel VPN implementation. 

Administrator permission restriction

Restricting administrator permissions so that most users cannot conduct administrator actions on their work computer, such as installing remote access/management software, can help limit an adversary’s ability to install this software after the initial compromise.

Applying the principle of least privilege, which includes both locking down local administrator permissions and limiting the permissions of users’ domain accounts, is considered standard best practice.

NAC controls

While network access control (NAC) solutions do not directly block the use of remote management software, they can ensure that all other technical controls are working properly before admitting an endpoint to the network. If the device is a rogue system or lacks EDR, for example, NAC would prevent it from joining.

Another benefit offered by a NAC solution is software version enforcement through custom rules. In Cisco ISE, for example, there are Posture Checks. Organizations can use this to ensure that only the approved version(s) of their approved remote management tool are allowed on the network, directly addressing the threat of an adversary introducing an older version of the approved solution to the network for malicious purposes.

Alerts and forensics

Due to the complexity of implementing all these controls, detection rules can serve as a backup in case an adversary finds a way to circumvent the previous mitigations we discussed. The possibilities for these “tripwire” detections are endless, and SOCs/threat-hunting teams should continuously think of ways to improve them, but some ideas are listed below.

Central log collection

The first prerequisite for any successful detections is to have centralized log aggregation. At the very minimum, this should ingest firewall logs, EDR alerts and Windows Event logs for key servers. 

SIEM alerts — Splunk

If your organization uses Splunk, the following pre-built detections match a variety of data sources against an actively maintained repository of hundreds of indicators for remote access software. The only prerequisite is data ingestion from the relevant security tool in the Common Information Model (CIM) format, which is made easy with Splunk’s pre-built apps.

SIEM alerts for suspicious strings

Setting up a simple alert that triggers upon observation of strings associated with unauthorized remote access/management software product names (e.g., “AnyDesk”) can be an effective way to proactively identify unexpected product installations that were not otherwise blocked.

For example, an MSI installation would generate an Event 11707 entry in the Windows Application Event logs containing the software product name. If the SIEM were ingesting and evaluating those event logs, it would fire an alert, thereby alerting the SOC to a potential installation. This rule would need to be tuned to avoid excessive false positives, but it could result in a valuable early detection method. 

SIEM alerts for firewall blocks on unique ports

Enhanced alerting may be necessary to draw a SOC’s attention to firewall blocks associated with remote management/access traffic. Firewalls continuously block traffic, generally dropping thousands or millions of packets per hour. With that in mind, SOCs are not alerted every time a firewall rule drops traffic — especially if the rule that drops the traffic is the Implicit Deny rule blocking all traffic that was not specifically allowed. However, if an internal host attempts to communicate over a port dedicated to remote access/management software, that might merit attention from the SOC. 

It's worth considering creating an SIEM rule that alerts on any firewall block event involving outbound traffic to certain key ports, for example, 5938 (associated with TeamViewer). That alert, while an indication that the network blocks are working as intended, would be a good indication that the SOC needs to investigate the system originating the traffic.

The level of effort required to properly secure remote management/access software is daunting. However, the frequency of use by adversaries makes that effort a necessity. In the wrong hands, these tools serve as a ready-made command and control mechanism. If an organization can afford to secure its VPN solution, it should almost certainly devote resources to locking down unauthorized remote management software, as well.