« First Time Seen NewCredentials Logon Process First Time Seen RMM Signer Across the Environment »
Elastic Docs ›Elastic Security [8.19] ›Detections and alerts ›Prebuilt rule reference

First Time Seen RMM Service Hostname from Network DNS

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

First Time Seen RMM Service Hostname from Network DNS

edit

Identifies when a source IP first queries a domain associated with commonly abused Remote Monitoring and Management (RMM) software within the seven-day new-terms history window. RMM tools are legitimate administration products, but adversaries frequently install or abuse them for command and control, persistence, and remote execution.

Rule type: new_terms

Rule indices:

  • logs-fortinet_fortigate.log-*
  • logs-network_traffic.dns-*
  • logs-suricata.eve-*
  • logs-zeek.dns-*
  • packetbeat-*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Network
  • Use Case: Network Security Monitoring
  • Use Case: Threat Detection
  • Tactic: Command and Control
  • Data Source: Fortinet FortiGate
  • Data Source: Network Packet Capture
  • Data Source: Network Traffic
  • Data Source: Suricata
  • Data Source: Zeek
  • Noise: Unknown
  • Resources: Investigation Guide
  • Rule Type: New Terms
  • Threat: Remote Management Tool Abuse

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating First Time Seen RMM Service Hostname from Network DNS

Remote Monitoring and Management (RMM) tools provide legitimate remote administration, but the same capabilities are frequently abused for initial access, persistence, command execution, and command and control. This rule identifies the first observed relationship between a DNS source and a curated RMM agent or service hostname, including ScreenConnect relay subdomains, within the seven-day new-terms history window. Novelty is evaluated independently for each source.ip and dns.question.registered_domain pair, not for the domain across the entire environment. Using the registered domain as the novelty key prevents multiple service hostnames under the same registered domain from generating separate alerts. Products that use multiple registered domains may generate more than one alert for the same client.

The alert does not prove malicious RMM use. Passive DNS does not identify the requesting process, and source.ip may represent a recursive resolver or forwarder depending on sensor placement.

Possible investigation steps

  • Review source.ip, dns.question.name, dns.question.registered_domain, dns.question.type, dns.response_code, and dns.resolved_ip. Confirm that source.ip represents an endpoint rather than shared DNS infrastructure.
  • Identify the asset and owner associated with source.ip using DHCP, asset inventory, endpoint telemetry, or network.community_id.
  • Determine which RMM product owns the queried hostname and whether that product is approved for this asset, user, and support window.
  • Search DNS and TLS events for the same client before and after the alert. Look for additional RMM vendors, repeated agent-control traffic, or connections to self-hosted relay infrastructure.
  • Correlate with the endpoint rules "First Time Seen Remote Monitoring and Management Tool" and "First Time Seen DNS Query to RMM Domain" when host telemetry is available.
  • Review process, file, service, and persistence activity on the resolved endpoint. Unexpected installers, scripting engines, user-writable execution paths, or remote-access services increase suspicion.
  • Check for preceding delivery or social-engineering activity and for follow-on credential access, lateral movement, or data staging.

False positive analysis

  • A newly deployed or newly observed approved RMM agent is expected to alert once for each client and registered domain.
  • Helpdesk, managed service provider, migration, and lab systems may legitimately contact several RMM services.
  • Browser access to a vendor service hostname can match because network DNS telemetry lacks process context.
  • Central resolvers can combine many endpoints under one source.ip. Do not create broad vendor exceptions until the actual endpoint and business owner are known.
  • Scope exceptions to a validated combination of client network or asset, hostname or domain, and approved operational context. Avoid globally excluding a vendor domain.

Response and remediation

  • If unauthorized RMM use is confirmed, preserve process, installer, service, account, and network evidence before containment.
  • Isolate the affected endpoint when active remote control or follow-on compromise is suspected.
  • Remove unauthorized RMM software and persistence, revoke active sessions, and rotate credentials exposed through the remote session.
  • Block confirmed unauthorized agent or relay domains where organizational policy permits.
  • Enforce an approved-RMM policy and retain DNS, TLS, and endpoint telemetry needed to distinguish authorized support from adversary use.

Setup

edit

Setup

This rule requires DNS transaction events from one of the following DNS telemetry sources:

  • Elastic Network Packet Capture (network_traffic.dns) in logs-network_traffic.dns-*
  • Fortinet FortiGate DNS logs (fortinet_fortigate.log) in logs-fortinet_fortigate.log-*
  • Suricata EVE DNS events (suricata.eve) in logs-suricata.eve-*
  • Zeek (zeek.dns) in logs-zeek.dns-*
  • Legacy Packetbeat DNS events in packetbeat-* with event.dataset set to dns

Place the sensor where it observes endpoint-to-resolver DNS traffic. If the sensor is upstream of a recursive resolver, source.ip may identify the resolver instead of the originating endpoint. DNS over HTTPS, DNS over TLS, cached answers, and asymmetric capture can create blind spots.

Rule query

edit
(
  data_stream.dataset:(fortinet_fortigate.log or network_traffic.dns or suricata.eve or zeek.dns)
  or event.dataset:dns
)
  and source.ip:*
  and dns.question.registered_domain:*
  and (
    dns.question.name:(
      *-relay.screenconnect.com or
      *-relay.screenconnect.com. or
      "agent-api.atera.com" or
      "agent-api.atera.com." or
      "agenthb.atera.com" or
      "agenthb.atera.com." or
      "agentreporting.atera.com" or
      "agentreporting.atera.com." or
      "agents.level.io" or
      "agents.level.io." or
      "api.rustdesk.com" or
      "api.rustdesk.com." or
      "assist.zoho.com" or
      "assist.zoho.com." or
      "boot.net.anydesk.com" or
      "boot.net.anydesk.com." or
      "cc.centrastage.net" or
      "cc.centrastage.net." or
      "client.teamviewer.com" or
      "client.teamviewer.com." or
      "control.connectwise.com" or
      "control.connectwise.com." or
      "deploy01.kaseya.com" or
      "deploy01.kaseya.com." or
      "gateway.zohoassist.com" or
      "gateway.zohoassist.com." or
      "geo.netsupportsoftware.com" or
      "geo.netsupportsoftware.com." or
      "ld.aurelius.host" or
      "ld.aurelius.host." or
      "managedsupport.kaseya.net" or
      "managedsupport.kaseya.net." or
      "ps.atera.com" or
      "ps.atera.com." or
      "pubsub.atera.com" or
      "pubsub.atera.com." or
      "rescue-data-center.logmein-gateway.com" or
      "rescue-data-center.logmein-gateway.com." or
      "router15.teamviewer.com" or
      "router15.teamviewer.com." or
      "rs-ny.rustdesk.com" or
      "rs-ny.rustdesk.com." or
      "serv.superopsalpha.com" or
      "serv.superopsalpha.com." or
      "taf.teamviewer.com" or
      "taf.teamviewer.com."
    )
  )

Framework: MITRE ATT&CKTM

« First Time Seen NewCredentials Logon Process First Time Seen RMM Signer Across the Environment »