1. Blumira Support
  2. Using Blumira
  3. Findings

Quick Links

Investigating "Remote Access Tool" findings

Overview

This guide provides helpful tips and considerations when investigating “Remote Access Tool” findings, which are triggered by remote monitoring and management (RMM) tool activity on a device. Ransomware operators use RMM tools to bypass detection by blending into environments, elevate privileges, move laterally, and maintain command and control. This tactic is why we built several detection rules to cover popular RMM tools on the market.

The group of “Remote Access Tool” findings includes the following:

  • Remote Access Tool: AnyDesk
  • Remote Access Tool: Atera
  • Remote Access Tool: GoToMyPC or GoToAssist
  • Remote Access Tool: LogMeIn
  • Remote Access Tool: NetSupport Manager
  • Remote Access Tool: RustDesk
  • Remote Access Tool: ScreenConnect
  • Remote Access Tool: Splashtop
  • Remote Access Tool: TeamViewer

Events that can trigger “Remote Access” findings

Below are some common cases and tips for investigating remote access findings.

Scenario Considerations
Known Tools You may already have an established RMM tool within the organization. Review and verify that it is expected to be active during the time when the activity occurred.
Unknown Tools

A new tool may have recently been added within your organization that you have not yet added to an allowlist, or it could be a threat actor. Review whether the tool is in your list of approved or unapproved RMM tools.

A proactive approach is to utilize ACLs to block URLs associated with RMM tools that are specifically not approved, such as the following:

  • AnyDesk *.net.anydesk[.]com 
  • Atera *.atera.com, ps.pndsn[.]com 
  • ConnectWise *.screenconnect[.]com 
  • LogMeIn *.logmein[.]com 
  • Splashtop *.splashtop[.]com 
  • TeamViewer *.teamviewer[.]com

Threat actors may try to hide the locations of RMM software. Look in odd directories such as “Public” or “Music” directories for these tools or any unexpected locations where an administrator in your organization would install them.

Interviewing end users can help to uncover how and why this tool was introduced on the device.
False Positives We have observed scans from Tenable trigger some of these detections. If the command activity shows Tenable scanning, you can filter out this activity by filtering the devname and a portion of the command from the scan. 

Using Report Builder to analyze logs

Reference: See Using the Report Builder for more information about building reports.

The “Remote Access Tool” findings are generated upon process creation. Usually, correlating the finding’s timestamp to known usage of the same tool within your organization is the most helpful way to verify if the activity is benign or malicious. Creating a report using the devname allows you to analyze the relevant logs from the device around the time of the finding.

While reviewing the report, look for the following information:

  • Behavior such as additional suspicious processes, commands, or user activity observed on the host that may indicate the presence of malicious or suspicious actors.
  • Commands executed on the affected host or additional activity associated with the RMM tool named in the finding. Be aware that RMM command logging is limited and is not always directly attributable to the tool, but reviewing the commands that were executed on the host may provide you helpful investigative context.
  • Network connections and DNS requests around the same time that are unexpected in your environment.

To review the device logs, do the following:

  1. Keeping the finding’s detail page open, open Report Builder in a new browser window so you can refer to the finding while reviewing data in a separate window.
  2. In Report Builder, set Time Range to include the timeframe of the finding’s activity.
  3. In Data Sources, select all Microsoft Windows and Blumira Agent data sources, if available. Alternatively, you can click Edit Report then click Select All Data Sources option to expand the dataset.
  4. Add a filter to the report where devname equals or contains part of the device name you need to investigate from the finding.
  5. Add columns to the report, such as those below, if available in the logs, which will provide you with helpful information from the logs:
    • timestamp
    • command
    • description
    • device_address
    • devname
    • domain
    • event_type
    • Image_path
    • message
    • object_path
    • parent.cmdline
    • parent_process_id
    • parent_process_name
    • privileges
    • process_id
    • process_name
    • service_name
    • service_type
    • shipping_agent
    • subject_account_name
    • type
    • user
    • windows_event_id
  6. Click Submit.
  7. To further refine your report to the specific RMM tool in question, refer to the additional filtering suggestions in the section below.

Report filters for specific tools

Tool Tips & Filters
AnyDesk

Creating a report for AnyDesk activity may help to show the Windows Event IDs and activity surrounding the tool. 

Looking specifically at event IDs 7045, 11707, and 1033 or event type NETWORK_CONNECTIONS may help to understand agent program installation by correlating the date and time of tool installation with the network connection activity from the named process.

Tip: Add more columns to this report, such as dst_ip and dst_port.

Suggested filters:

  • event_type – Equal – NETWORK_CONNECTIONS
    AND
    process_name – Regex –  (?i)anydesk
  • event_type – Equal – DNS_REQUEST
    AND
    dns_name – Regex – (?i)anydesk
  • windows_event_id – Equal –  4688
    AND
    process_name – Contains –  anydesk
Atera

Creating a report for Atera activity may help to show the Windows Event IDs and the activity surrounding the tool. Looking specifically at event IDs 7045, 4688, 11707, 1033, 4104, and 400 may help to understand activity, such as verifying the dates and times related to agent program or tool installations, process activity, or PowerShell scripts.

You can also look into the NETWORK_CONNECTIONS event type which may help to highlight network connection activity from the process. Regarding 3rd party remote access tool integration, the logs above should indicate Atera usage of those additional tools. 

Tip: Add more filters to the report such as dst_ip, dst_port, and/or info depending on the filters applied. The info field should show successful installation and help to correlate timestamp details.

Suggested filters:

  • windows_event_id – Equal – 4104
    AND
    object_path – Contains –  atera
  • windows_event_id – Equal –  4688
    AND
    process_name – Contains –  atera
  • windows_event_id – In –  11707, 1033
  • event_type – Equal – NETWORK_CONNECTIONS
    AND
    process_name – Regex –  (?i)atera
  • windows_event_id – Equal – 7045
    AND
    image_path – Contains –  atera
    Tip: Not adding the image_path filter and instead looking at all 7045 events may help for the scope timeframe of investigation. In conjunction with event ID 7045, you can often correlate this activity to event ID 4697 and review details in the file_name, file_path, and user fields.
LogMeIn

Creating a report for LogMeIn activity may help to show the Windows Event IDs, and the activity surrounding the tool. 

Looking specifically at event IDs 7045, 11707, and 1033 or event type NETWORK_CONNECTIONS may help to understand agent program installation by correlating the date and time of tool installation with the network connection activity from the named process.

Tip: Add more filters to the report such as dst_ip, dst_port, and/or info depending on the filters applied. The info field should show successful installation and help to correlate timestamp details.

Suggested filters:

  • event_type – Equal – NETWORK_CONNECTIONS
    AND
    process_name – Regex –  (?i)logmein
  • windows_event_id – Equal – 7045
    AND
    image_path – Contains – logmein 
  • windows_event_id – In –  11707, 1033
ScreenConnect

Creating a report for ScreenConnect activity may help you to find the Instance ID. You can then use this Instance ID to verify if it is an approved or unapproved instance of ScreenConnect software. 

Below is an example of a report where we try to look for the Instance ID in the command, process_name, or parent_process_name fields:

Example: C:\Program Files(x86)\ScreenConnect Client (<Instance_ID>)\ScreenConnect.ClientService.exe

Suggested filters:

  • process_name – Contains –  screenconnect
  • command – Contains –  screenconnect
  • windows_event_id – In – 4688, 600, 400, 403, 4104
  • windows_event_id – In – 600, 400, 403
    Note: The Windows Event ID 403 has the "HostApplication=<ps_command_and_file_path>" data located in the info field. You should be able to identify ScreenConnect-related PowerShell execution, although few details are logged.
  • windows_event_id – Equal – 4104
    AND
    object_path – Contains – screenconnect
    Note: The Windows Event ID 4104 should show specific details under object_path if script block logging is enabled.
Splashtop

Creating a report for Splashtop activity may help to show the Windows Event IDs, and the activity surrounding the tool. 

Looking specifically at event IDs 7045, 11707, and 1033 or event type NETWORK_CONNECTIONS may help to understand agent program installation by correlating the date and time of tool installation with the network connection activity from the named process.

Tip: Add more filters to the report such as dst_ip, dst_port, and/or info depending on the filters applied. The info field should show successful installation and help to correlate timestamp details.

Suggested filters:

  • event_type – Equal – NETWORK_CONNECTIONS
    AND
    process_name – Regex – (?i)splashtop 
  • windows_event_id – Equal – 7045
    AND
    image_path – contains – splashtop 
  • windows_event_id – In – 11707, 1033
TeamViewer

Creating a report for TeamViewer activity may help to show the Windows Event IDs, and the activity surrounding the tool. 

Looking specifically at event IDs 7045, 11707, and 1033 or event type NETWORK_CONNECTIONS may help to understand agent program installation by correlating the date and time of tool installation with the network connection activity from the named process.

Tip: Add more sources like dst_ip, dst_port, and user.

Suggested filters:

  • event_type – Equal – – Equal – NETWORK_CONNECTIONS
    AND
    process_name – Regex – (?i)teamviewer  
  • windows_event_id – Equal – 7045
    AND
    image_path – Contains – teamviewer 
  • event_type – Equal – – Equal – NETWORK_CONNECTIONS
    AND
    process_name – Contains – teamviewer
  • event_type – Equal – DNS_REQUEST
    AND
    dns_name – Contains – teamviewer or known_domain or subdomain_name
  • windows_event_id – Equal – 4104
    AND
    object_path – Contains – teamviewer
  • windows_event_id – Equal – 7045
    AND
    image_path – Contains – teamviewer
    windows_event_id – Equal – 4688
    AND
    process_name – Contains – teamviewer

Adding detection filters

We have previously observed RMM tools being compromised and therefore do not recommend filtering the processes from detection. However, it may be worth considering how to balance alert fatigue with these particular findings.

Because these detections are based on process creation and observe the tool being executed in your environment, we recommend creating detection filters based on the device names in the findings. You can utilize the “IN” operator to add devname when this activity occurs. 

To minimize alert fatigue when you have authorized RMM tools that are always expected to be present in your environment, you can disable this detection entirely instead of reactively adding detection filters.

Lastly, we have observed scans from Tenable trigger some of these detections. If the command activity shows Tenable scanning, you can filter out this activity by adding a filter that is a combination of the devname and a portion of the command from the Tenable scan. 

Related Articles