First Time Seen RMM Signer Across the Environment

Identifies a newly observed RMM-related code-signature subject across the Windows Elastic Defend hosts. Attackers often use RMM tools to gain remote access to victim machines and deploy malware.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/07/28"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2026/07/28"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies a newly observed RMM-related code-signature subject across the Windows Elastic Defend hosts. Attackers often
 11use RMM tools to gain remote access to victim machines and deploy malware.
 12"""
 13from = "now-9m"
 14index = ["logs-endpoint.events.process-*"]
 15language = "kuery"
 16license = "Elastic License v2"
 17name = "First Time Seen RMM Signer Across the Environment"
 18references = [
 19    "https://thedfirreport.com/2023/04/03/malicious-iso-file-leads-to-domain-wide-ransomware/",
 20    "https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-025a",
 21    "https://www.cisa.gov/sites/default/files/2025-06/aa25-163a-ransomware-simplehelp-rmm-compromise.pdf",
 22    "https://lolrmm.io/",
 23]
 24risk_score = 47
 25rule_id = "bb8dac47-0271-4000-b4e3-1bfc75eec5c4"
 26setup = """## Setup
 27
 28This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
 29
 30Setup instructions: https://ela.st/install-elastic-defend
 31"""
 32severity = "medium"
 33tags = [
 34    "Domain: Endpoint",
 35    "OS: Windows",
 36    "Use Case: Threat Detection",
 37    "Tactic: Command and Control",
 38    "Resources: Investigation Guide",
 39    "Data Source: Elastic Defend",
 40]
 41timestamp_override = "event.ingested"
 42type = "new_terms"
 43
 44query = '''
 45host.os.type: "windows" and
 46event.category: "process" and event.type: "start" and
 47process.code_signature.subject_name: (
 48    "Action1 Corporation" or
 49    "Aeroadmin LLC" or
 50    "AeroAdmin LLC" or
 51    "AmidaWare LLC" or
 52    "Ammyy LLC" or
 53    "AnyDesk Software GmbH" or
 54    "AOMEI International Network Limited" or
 55    "Atera Networks Ltd" or
 56    "AWERAY PTE. LTD." or
 57    "BeamYourScreen GmbH" or
 58    "Bomgar Corporation" or
 59    "BreakingSecurity.net" or
 60    "ConnectWise, Inc." or
 61    "ConnectWise, LLC" or
 62    "Connectwise, LLC" or
 63    "Devolutions Inc" or
 64    "Devolutions inc." or
 65    "DOMOTZ INC." or
 66    "DUC FABULOUS CO.,LTD" or
 67    "DWSNET OÜ" or
 68    "DWSNET srl" or
 69    "Electronic Team, Inc." or
 70    "Famatech Corp." or
 71    "FleetDeck Inc" or
 72    "GlavSoft LLC" or
 73    "GlavSoft LLC." or
 74    "GoTo Technologies USA, LLC" or
 75    "Hefei Pingbo Network Technology Co. Ltd" or
 76    "IDrive, Inc." or
 77    "Impero Solutions Limited" or
 78    "IMPERO SOLUTIONS LIMITED" or
 79    "Instant Housecall" or
 80    "ISL Online Ltd." or
 81    "JumpCloud Inc" or
 82    "Level Software, Inc." or
 83    "LogMeIn, Inc." or
 84    "LUNIXAR SAS DE CV" or
 85    "MMSOFT Design Ltd." or
 86    "Monitoring Client" or
 87    "MSPBytes Corp" or
 88    "MSPBytes, Corp." or
 89    "N-ABLE TECHNOLOGIES LTD" or
 90    "Nanosystems S.r.l." or
 91    "NetSupport Ltd" or
 92    "NetSupport Ltd." or
 93    "NETSUPPORT LTD." or
 94    "NinjaOne LLC" or
 95    "NinjaRMM, LLC" or
 96    "Open Source Developer, Huabing Zhou" or
 97    "Parallels International GmbH" or
 98    "philandro Software GmbH" or
 99    "Pro Softnet Corporation" or
100    "PURSLANE" or
101    "RealVNC" or
102    "RealVNC Limited" or
103    "REMOTE UTILITIES PTE. LTD." or
104    "Remote Utilities LLC" or
105    "Rocket Software, Inc." or
106    "Rsupport Co., Ltd." or
107    "SAFIB" or
108    "ScreenConnect Client" or
109    "Servably, Inc." or
110    "Servably Inc." or
111    "ShowMyPC INC" or
112    "SimpleHelp Ltd" or
113    "Splashtop Inc." or
114    "Superops Inc." or
115    "Tailscale Inc." or
116    "TeamViewer" or
117    "TeamViewer GmbH" or
118    "TeamViewer Germany GmbH" or
119    "Techinline Limited" or
120    "uvnc bvba" or
121    "Yakhnovets Denis Aleksandrovich IP" or
122    "Zhou Huabing" or
123    "ZOHO Corporation Private Limited"
124)
125'''
126
127
128note = """## Triage and analysis
129
130### Investigating First Time Seen RMM Signer Across the Environment
131
132Attackers abuse legitimate RMM and remote-access software to open interactive sessions, persist, and stage follow-on tooling while blending into IT support activity. This rule alerts on a Windows Elastic Defend process start whose `process.code_signature.subject_name` matches a curated vendor list, when that subject is first seen across the visible fleet in the 10-day new_terms history window. Novelty is keyed only on the signer subject, so each certificate string alerts once environment-wide and renamed binaries that still carry a listed signer still match. Signature trust is not a query condition; review `process.code_signature.trusted` as context only.
133
134#### Possible investigation steps
135
136- Is the matched binary a remote-access component, or an unrelated product that shares this signer?
137  - Focus: `process.executable`, `process.name`, `process.pe.original_file_name`, `process.command_line`.
138  - Review the other binaries this signer started on the alerted host with $investigate_0
139  - Implication: Several vendors on this list also ship backup, virtualization, terminal-emulation, and management software under the same certificate, so a signer's first appearance is often not its remote-access product. A path, original file name, and command line matching the vendor's remote-access agent keeps that hypothesis active. An unrelated product from the same vendor makes this a low-value observation that still consumes the signer's novelty term, so confirm the vendor's remote-access footprint now rather than waiting for a later alert this rule will not produce.
140- Does the parent and session context explain why this process launched on this host?
141  - Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, `process.Ext.token.elevation_level`, `user.name`.
142  - Retrieve the parent process event while the parent entity is still retained with $investigate_1
143  - Implication: A parent consistent with a software-deployment service or a scheduled management task keeps this inside a rollout hypothesis. A launch from a browser, archive, mail client, script interpreter, or an unexpected interactive session points instead to social engineering or staged access.
144- What did the matched process start after launch?
145  - Focus: child `process.name`, `process.command_line`, `process.parent.entity_id`.
146  - Review child process starts on the same host with $investigate_2
147  - Implication: No child process evidence is unresolved, not benign. Children limited to the vendor's own service and updater binaries stay consistent with normal tool operation without proving the deployment was authorized, while child shells, script interpreters, discovery commands, or credential tooling are suspicious.
148- Did the same process perform remote-access network activity that changes the host scope?
149  - Focus: `destination.ip`, `destination.port`, `network.direction`.
150  - Review endpoint network events for the same process entity with $investigate_3
151  - Implication: Missing network telemetry is unresolved, not benign. Sessions to the vendor's own service endpoints show the tool operating normally but do not establish who initiated the session, while connections to unrelated external infrastructure keep the case open for escalation and wider scoping.
152- If local evidence is suspicious or unresolved, is the same signer or executable hash appearing beyond the alerted host?
153  - Focus: `process.code_signature.subject_name`, `process.hash.sha256`, `process.executable`, `host.name`, `user.name`.
154  - Review recent process starts sharing the matched signer or executable hash with $investigate_4; the pivot is bounded to the last 24 hours for performance, so widen the Timeline range when the deployment window or suspected activity is older.
155  - Implication: Additional hosts or users shift the hypothesis from a single host deployment to an environment-wide remote-access introduction and should expand response scope. This rule reports a signer once for the whole fleet, so it will not alert again for this vendor and will not alert at all on a renamed binary reusing an already-observed signer; a clean 24-hour pivot therefore bounds recent spread only and is not evidence that spread has stopped.
156
157After these checks, escalate when source process, parent, network, or cross-host evidence is suspicious; close only when alert-local and recovered evidence prove the exact expected host/user/signer/hash scope with verified owner confirmation; preserve and escalate mixed or incomplete cases for more context.
158
159### False positive analysis
160
161- This rule can alert on a real but expected first appearance of a listed signer when a software rollout, support session, or vendor agent introduction reaches the Elastic Defend fleet for the first time in the 10-day history window.
162- Treat benign disposition as evidence-bounded: the alert's `process.code_signature.subject_name`, `process.executable`, `process.hash.sha256`, `host.id`, `host.name`, `user.id`, and `user.domain` should match a validated change record or verified owner confirmation for the exact system and activity.
163- Treat `process.code_signature.trusted` as contextual evidence, not clearance: a trusted signature does not establish authorization or benign intent, and an untrusted, invalid, or missing trust value does not by itself prove malicious use.
164- Certificate subjects that differ only in case or punctuation are separate novelty terms, so a single vendor can produce more than one alert as its certificate strings drift across products and releases. Correlate those and treat them as one introduction rather than as repeat findings.
165- When justified, scope an exception conjunctively to the exact `process.code_signature.subject_name` plus `process.executable`, further bounded by supported host/user anchors such as `host.id`, `host.name`, `user.id`, or `user.domain`; never exclude on signer alone. `process.hash.sha256` is precise for scoping one investigation but is not a durable exception anchor, because the vendor's next release changes it and the exception silently stops matching.
166- Expect an exception to have limited effect here, because the first alert already consumes that signer's novelty term for the history window; an exception only applies if the signer disappears from the visible fleet for more than 10 days and returns. `user.name` appears in the Focus lines for readability during analysis, while exception criteria prefer `user.id` and `user.domain` as stable identifiers rather than display names.
167
168### Response and remediation
169
170- Preserve or export case evidence plus volatile process, memory, executable, and file-system artifacts that could be lost before isolation, process termination, cleanup, or other disruptive action.
171- Scope the activity by signer, executable hash, process entity, host, and user before containment; include child processes, same-process network events when available, and any later hosts that show the same signer or hash.
172- If malicious use is confirmed, contain affected hosts through the endpoint response integration when available and contain affected accounts using reversible controls first; if direct endpoint response is unavailable, document the collected evidence and artifacts and hand them off to the responsible endpoint or incident-response team able to act. After evidence collection and scoping, terminate malicious processes, remove persistence, and clean up remote-access tooling.
173- Review collected evidence for credential exposure, lateral movement, and follow-on tooling before final remediation decisions.
174- Document confirmed indicators and any logging or detection gaps for the responsible detection or logging owners after scoping and containment.
175"""
176
177[rule.investigation_fields]
178field_names = [
179    "@timestamp",
180    "host.id",
181    "host.name",
182    "user.id",
183    "user.name",
184    "user.domain",
185    "process.entity_id",
186    "process.parent.entity_id",
187    "process.code_signature.subject_name",
188    "process.code_signature.trusted",
189    "process.name",
190    "process.executable",
191    "process.pe.original_file_name",
192    "process.command_line",
193    "process.hash.sha256",
194    "process.Ext.session_info.logon_type",
195    "process.Ext.token.elevation_level",
196]
197
198
199[[transform.investigate]]
200label = "Signer footprint on the alerted host"
201description = "Show which binaries sharing the matched code-signature subject started on the alerted host during the investigation window."
202providers = [[
203    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
204    { excluded = false, field = "process.code_signature.subject_name", queryType = "phrase", value = "{{process.code_signature.subject_name}}", valueType = "string" },
205    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
206    { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" },
207]]
208relativeFrom = "now-24h/h"
209relativeTo = "now"
210
211[[transform.investigate]]
212label = "Parent process context"
213description = "Find the parent process event for the matched launch when the parent entity is retained."
214providers = [[
215    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
216    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.parent.entity_id}}", valueType = "string" },
217    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
218]]
219relativeFrom = "now-24h/h"
220relativeTo = "now"
221
222[[transform.investigate]]
223label = "Child process starts"
224description = "Find child process starts spawned by the matched process on the same host."
225providers = [[
226    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
227    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
228    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
229    { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" },
230]]
231relativeFrom = "now-24h/h"
232relativeTo = "now"
233
234[[transform.investigate]]
235label = "Same-process network events"
236description = "Search for endpoint network events tied to the matched process entity on the same host."
237providers = [[
238    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
239    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
240    { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" },
241]]
242relativeFrom = "now-24h/h"
243relativeTo = "now"
244
245[[transform.investigate]]
246label = "Recent signer and hash spread"
247description = "Search the 24-hour investigation window for process starts that share the matched signer or executable hash. Widen the Timeline range to look further back."
248providers = [[
249    { excluded = false, field = "process.code_signature.subject_name", queryType = "phrase", value = "{{process.code_signature.subject_name}}", valueType = "string" },
250    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
251    { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" },
252], [
253    { excluded = false, field = "process.hash.sha256", queryType = "phrase", value = "{{process.hash.sha256}}", valueType = "string" },
254    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
255    { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" },
256]]
257relativeFrom = "now-24h/h"
258relativeTo = "now"
259
260[[rule.threat]]
261framework = "MITRE ATT&CK"
262[[rule.threat.technique]]
263id = "T1219"
264name = "Remote Access Tools"
265reference = "https://attack.mitre.org/techniques/T1219/"
266[[rule.threat.technique.subtechnique]]
267id = "T1219.002"
268name = "Remote Desktop Software"
269reference = "https://attack.mitre.org/techniques/T1219/002/"
270
271
272
273[rule.threat.tactic]
274id = "TA0011"
275name = "Command and Control"
276reference = "https://attack.mitre.org/tactics/TA0011/"
277
278[rule.new_terms]
279field = "new_terms_fields"
280value = ["process.code_signature.subject_name"]
281[[rule.new_terms.history_window_start]]
282field = "history_window_start"
283value = "now-10d"

Triage and analysis

Investigating First Time Seen RMM Signer Across the Environment

Attackers abuse legitimate RMM and remote-access software to open interactive sessions, persist, and stage follow-on tooling while blending into IT support activity. This rule alerts on a Windows Elastic Defend process start whose process.code_signature.subject_name matches a curated vendor list, when that subject is first seen across the visible fleet in the 10-day new_terms history window. Novelty is keyed only on the signer subject, so each certificate string alerts once environment-wide and renamed binaries that still carry a listed signer still match. Signature trust is not a query condition; review process.code_signature.trusted as context only.

Possible investigation steps

  • Is the matched binary a remote-access component, or an unrelated product that shares this signer?
    • Focus: process.executable, process.name, process.pe.original_file_name, process.command_line.
    • Review the other binaries this signer started on the alerted host with $investigate_0
    • Implication: Several vendors on this list also ship backup, virtualization, terminal-emulation, and management software under the same certificate, so a signer's first appearance is often not its remote-access product. A path, original file name, and command line matching the vendor's remote-access agent keeps that hypothesis active. An unrelated product from the same vendor makes this a low-value observation that still consumes the signer's novelty term, so confirm the vendor's remote-access footprint now rather than waiting for a later alert this rule will not produce.
  • Does the parent and session context explain why this process launched on this host?
    • Focus: process.parent.executable, process.parent.command_line, process.Ext.session_info.logon_type, process.Ext.token.elevation_level, user.name.
    • Retrieve the parent process event while the parent entity is still retained with $investigate_1
    • Implication: A parent consistent with a software-deployment service or a scheduled management task keeps this inside a rollout hypothesis. A launch from a browser, archive, mail client, script interpreter, or an unexpected interactive session points instead to social engineering or staged access.
  • What did the matched process start after launch?
    • Focus: child process.name, process.command_line, process.parent.entity_id.
    • Review child process starts on the same host with $investigate_2
    • Implication: No child process evidence is unresolved, not benign. Children limited to the vendor's own service and updater binaries stay consistent with normal tool operation without proving the deployment was authorized, while child shells, script interpreters, discovery commands, or credential tooling are suspicious.
  • Did the same process perform remote-access network activity that changes the host scope?
    • Focus: destination.ip, destination.port, network.direction.
    • Review endpoint network events for the same process entity with $investigate_3
    • Implication: Missing network telemetry is unresolved, not benign. Sessions to the vendor's own service endpoints show the tool operating normally but do not establish who initiated the session, while connections to unrelated external infrastructure keep the case open for escalation and wider scoping.
  • If local evidence is suspicious or unresolved, is the same signer or executable hash appearing beyond the alerted host?
    • Focus: process.code_signature.subject_name, process.hash.sha256, process.executable, host.name, user.name.
    • Review recent process starts sharing the matched signer or executable hash with $investigate_4; the pivot is bounded to the last 24 hours for performance, so widen the Timeline range when the deployment window or suspected activity is older.
    • Implication: Additional hosts or users shift the hypothesis from a single host deployment to an environment-wide remote-access introduction and should expand response scope. This rule reports a signer once for the whole fleet, so it will not alert again for this vendor and will not alert at all on a renamed binary reusing an already-observed signer; a clean 24-hour pivot therefore bounds recent spread only and is not evidence that spread has stopped.

After these checks, escalate when source process, parent, network, or cross-host evidence is suspicious; close only when alert-local and recovered evidence prove the exact expected host/user/signer/hash scope with verified owner confirmation; preserve and escalate mixed or incomplete cases for more context.

False positive analysis

  • This rule can alert on a real but expected first appearance of a listed signer when a software rollout, support session, or vendor agent introduction reaches the Elastic Defend fleet for the first time in the 10-day history window.
  • Treat benign disposition as evidence-bounded: the alert's process.code_signature.subject_name, process.executable, process.hash.sha256, host.id, host.name, user.id, and user.domain should match a validated change record or verified owner confirmation for the exact system and activity.
  • Treat process.code_signature.trusted as contextual evidence, not clearance: a trusted signature does not establish authorization or benign intent, and an untrusted, invalid, or missing trust value does not by itself prove malicious use.
  • Certificate subjects that differ only in case or punctuation are separate novelty terms, so a single vendor can produce more than one alert as its certificate strings drift across products and releases. Correlate those and treat them as one introduction rather than as repeat findings.
  • When justified, scope an exception conjunctively to the exact process.code_signature.subject_name plus process.executable, further bounded by supported host/user anchors such as host.id, host.name, user.id, or user.domain; never exclude on signer alone. process.hash.sha256 is precise for scoping one investigation but is not a durable exception anchor, because the vendor's next release changes it and the exception silently stops matching.
  • Expect an exception to have limited effect here, because the first alert already consumes that signer's novelty term for the history window; an exception only applies if the signer disappears from the visible fleet for more than 10 days and returns. user.name appears in the Focus lines for readability during analysis, while exception criteria prefer user.id and user.domain as stable identifiers rather than display names.

Response and remediation

  • Preserve or export case evidence plus volatile process, memory, executable, and file-system artifacts that could be lost before isolation, process termination, cleanup, or other disruptive action.
  • Scope the activity by signer, executable hash, process entity, host, and user before containment; include child processes, same-process network events when available, and any later hosts that show the same signer or hash.
  • If malicious use is confirmed, contain affected hosts through the endpoint response integration when available and contain affected accounts using reversible controls first; if direct endpoint response is unavailable, document the collected evidence and artifacts and hand them off to the responsible endpoint or incident-response team able to act. After evidence collection and scoping, terminate malicious processes, remove persistence, and clean up remote-access tooling.
  • Review collected evidence for credential exposure, lateral movement, and follow-on tooling before final remediation decisions.
  • Document confirmed indicators and any logging or detection gaps for the responsible detection or logging owners after scoping and containment.

References

Related rules

to-top