First Time Seen RMM Service Hostname from Network DNS

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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/09/30"
  3integration = ["fortinet_fortigate", "network_traffic", "suricata", "zeek"]
  4maturity = "production"
  5updated_date = "2026/09/30"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies when a source IP first queries a domain associated with commonly abused Remote Monitoring and Management
 11(RMM) software within the seven-day new-terms history window. RMM tools are legitimate administration products, but
 12adversaries frequently install or abuse them for command and control, persistence, and remote execution.
 13"""
 14false_positives = [
 15    """
 16    Approved RMM deployments, one-time support sessions, product migrations, and security testing can trigger this rule.
 17    Recursive resolvers or DNS forwarders can also appear as the client when sensor placement does not preserve the
 18    originating endpoint address.
 19    """,
 20]
 21from = "now-9m"
 22index = [
 23    "logs-fortinet_fortigate.log-*",
 24    "logs-network_traffic.dns-*",
 25    "logs-suricata.eve-*",
 26    "logs-zeek.dns-*",
 27    "packetbeat-*",
 28]
 29language = "kuery"
 30license = "Elastic License v2"
 31name = "First Time Seen RMM Service Hostname from Network DNS"
 32note = """## Triage and analysis
 33
 34### Investigating First Time Seen RMM Service Hostname from Network DNS
 35
 36Remote Monitoring and Management (RMM) tools provide legitimate remote administration, but the same capabilities are
 37frequently abused for initial access, persistence, command execution, and command and control. This rule identifies the
 38first observed relationship between a DNS source and a curated RMM agent or service hostname, including ScreenConnect
 39relay subdomains, within the seven-day new-terms history window. Novelty is evaluated independently for each `source.ip`
 40and `dns.question.registered_domain` pair, not for the domain across the entire environment. Using the registered domain
 41as the novelty key prevents multiple service hostnames under the same registered domain from generating separate
 42alerts. Products that use multiple registered domains may generate more than one alert for the same client.
 43
 44The alert does not prove malicious RMM use. Passive DNS does not identify the requesting process, and `source.ip` may
 45represent a recursive resolver or forwarder depending on sensor placement.
 46
 47### Possible investigation steps
 48
 49- Review `source.ip`, `dns.question.name`, `dns.question.registered_domain`, `dns.question.type`, `dns.response_code`, and
 50  `dns.resolved_ip`. Confirm that `source.ip` represents an endpoint rather than shared DNS infrastructure.
 51- Identify the asset and owner associated with `source.ip` using DHCP, asset inventory, endpoint telemetry, or
 52  `network.community_id`.
 53- Determine which RMM product owns the queried hostname and whether that product is approved for this asset, user, and
 54  support window.
 55- Search DNS and TLS events for the same client before and after the alert. Look for additional RMM vendors, repeated
 56  agent-control traffic, or connections to self-hosted relay infrastructure.
 57- Correlate with the endpoint rules "First Time Seen Remote Monitoring and Management Tool" and "First Time Seen DNS
 58  Query to RMM Domain" when host telemetry is available.
 59- Review process, file, service, and persistence activity on the resolved endpoint. Unexpected installers, scripting
 60  engines, user-writable execution paths, or remote-access services increase suspicion.
 61- Check for preceding delivery or social-engineering activity and for follow-on credential access, lateral movement, or
 62  data staging.
 63
 64### False positive analysis
 65
 66- A newly deployed or newly observed approved RMM agent is expected to alert once for each client and registered domain.
 67- Helpdesk, managed service provider, migration, and lab systems may legitimately contact several RMM services.
 68- Browser access to a vendor service hostname can match because network DNS telemetry lacks process context.
 69- Central resolvers can combine many endpoints under one `source.ip`. Do not create broad vendor exceptions until the
 70  actual endpoint and business owner are known.
 71- Scope exceptions to a validated combination of client network or asset, hostname or domain, and approved operational
 72  context. Avoid globally excluding a vendor domain.
 73
 74### Response and remediation
 75
 76- If unauthorized RMM use is confirmed, preserve process, installer, service, account, and network evidence before
 77  containment.
 78- Isolate the affected endpoint when active remote control or follow-on compromise is suspected.
 79- Remove unauthorized RMM software and persistence, revoke active sessions, and rotate credentials exposed through the
 80  remote session.
 81- Block confirmed unauthorized agent or relay domains where organizational policy permits.
 82- Enforce an approved-RMM policy and retain DNS, TLS, and endpoint telemetry needed to distinguish authorized support
 83  from adversary use.
 84"""
 85references = [
 86    "https://attack.mitre.org/techniques/T1219/",
 87    "https://attack.mitre.org/techniques/T1219/002/",
 88    "https://github.com/magicsword-io/LOLRMM/",
 89    "https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-025a",
 90    "https://www.elastic.co/security-labs/tollbooth",
 91    "https://www.proofpoint.com/us/blog/threat-insight/remote-monitoring-and-management-rmm-tooling-increasingly-attackers-first-choice",
 92]
 93risk_score = 47
 94rule_id = "e73f0535-781b-4a3b-9042-5d993938f8d9"
 95setup = """## Setup
 96
 97This rule requires DNS transaction events from one of the following DNS telemetry sources:
 98
 99- Elastic Network Packet Capture (`network_traffic.dns`) in `logs-network_traffic.dns-*`
100- Fortinet FortiGate DNS logs (`fortinet_fortigate.log`) in `logs-fortinet_fortigate.log-*`
101- Suricata EVE DNS events (`suricata.eve`) in `logs-suricata.eve-*`
102- Zeek (`zeek.dns`) in `logs-zeek.dns-*`
103- Legacy Packetbeat DNS events in `packetbeat-*` with `event.dataset` set to `dns`
104
105Place the sensor where it observes endpoint-to-resolver DNS traffic. If the sensor is upstream of a recursive resolver,
106`source.ip` may identify the resolver instead of the originating endpoint. DNS over HTTPS, DNS over TLS, cached answers,
107and asymmetric capture can create blind spots.
108"""
109severity = "medium"
110tags = [
111    "Domain: Network",
112    "Use Case: Network Security Monitoring",
113    "Use Case: Threat Detection",
114    "Tactic: Command and Control",
115    "Data Source: Fortinet FortiGate",
116    "Data Source: Network Packet Capture",
117    "Data Source: Network Traffic",
118    "Data Source: Suricata",
119    "Data Source: Zeek",
120    "Noise: Unknown",
121    "Resources: Investigation Guide",
122    "Rule Type: New Terms",
123    "Threat: Remote Management Tool Abuse",
124]
125timestamp_override = "event.ingested"
126type = "new_terms"
127
128query = '''
129(
130  data_stream.dataset:(fortinet_fortigate.log or network_traffic.dns or suricata.eve or zeek.dns)
131  or event.dataset:dns
132)
133  and source.ip:*
134  and dns.question.registered_domain:*
135  and (
136    dns.question.name:(
137      *-relay.screenconnect.com or
138      *-relay.screenconnect.com. or
139      "agent-api.atera.com" or
140      "agent-api.atera.com." or
141      "agenthb.atera.com" or
142      "agenthb.atera.com." or
143      "agentreporting.atera.com" or
144      "agentreporting.atera.com." or
145      "agents.level.io" or
146      "agents.level.io." or
147      "api.rustdesk.com" or
148      "api.rustdesk.com." or
149      "assist.zoho.com" or
150      "assist.zoho.com." or
151      "boot.net.anydesk.com" or
152      "boot.net.anydesk.com." or
153      "cc.centrastage.net" or
154      "cc.centrastage.net." or
155      "client.teamviewer.com" or
156      "client.teamviewer.com." or
157      "control.connectwise.com" or
158      "control.connectwise.com." or
159      "deploy01.kaseya.com" or
160      "deploy01.kaseya.com." or
161      "gateway.zohoassist.com" or
162      "gateway.zohoassist.com." or
163      "geo.netsupportsoftware.com" or
164      "geo.netsupportsoftware.com." or
165      "ld.aurelius.host" or
166      "ld.aurelius.host." or
167      "managedsupport.kaseya.net" or
168      "managedsupport.kaseya.net." or
169      "ps.atera.com" or
170      "ps.atera.com." or
171      "pubsub.atera.com" or
172      "pubsub.atera.com." or
173      "rescue-data-center.logmein-gateway.com" or
174      "rescue-data-center.logmein-gateway.com." or
175      "router15.teamviewer.com" or
176      "router15.teamviewer.com." or
177      "rs-ny.rustdesk.com" or
178      "rs-ny.rustdesk.com." or
179      "serv.superopsalpha.com" or
180      "serv.superopsalpha.com." or
181      "taf.teamviewer.com" or
182      "taf.teamviewer.com."
183    )
184  )
185'''
186
187
188[[rule.threat]]
189framework = "MITRE ATT&CK"
190[[rule.threat.technique]]
191id = "T1219"
192name = "Remote Access Tools"
193reference = "https://attack.mitre.org/techniques/T1219/"
194[[rule.threat.technique.subtechnique]]
195id = "T1219.002"
196name = "Remote Desktop Software"
197reference = "https://attack.mitre.org/techniques/T1219/002/"
198
199
200
201[rule.threat.tactic]
202id = "TA0011"
203name = "Command and Control"
204reference = "https://attack.mitre.org/tactics/TA0011/"
205
206[rule.investigation_fields]
207field_names = [
208    "@timestamp",
209    "source.ip",
210    "server.ip",
211    "dns.question.name",
212    "dns.question.registered_domain",
213    "dns.question.type",
214    "dns.response_code",
215    "dns.resolved_ip",
216    "network.community_id",
217    "observer.name",
218]
219
220[rule.new_terms]
221field = "new_terms_fields"
222value = ["source.ip", "dns.question.registered_domain"]
223[[rule.new_terms.history_window_start]]
224field = "history_window_start"
225value = "now-7d"

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.

References

Related rules

to-top