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, anddns.resolved_ip. Confirm thatsource.iprepresents an endpoint rather than shared DNS infrastructure. - Identify the asset and owner associated with
source.ipusing DHCP, asset inventory, endpoint telemetry, ornetwork.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
- Multiple RMM Vendors Queried by a Single DNS Client
- First Seen External MQTT Broker Connection
- Splunk Enterprise PostgreSQL Backup-to-Restore Potential RCE Sequence
- Splunk Enterprise PostgreSQL Recovery Endpoint Injection Artifacts
- Potential DNS Tunneling via NULL or Long DNS Queries