Newly Observed ScreenConnect Host Server
Detects when the ScreenConnect client (ConnectWise Control) connects to a newly observed host server that is not the official ScreenConnect cloud. ScreenConnect is a common RMM/remote access tool abused for C2 and persistence. Self-hosted or non-standard relay servers may indicate abuse or compromise. The rule aggregates by server host (parsed from the client command line), requires first-time observation within the rule window, and limits to a single host to reduce noise.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/03/09"
3integration = ["endpoint"]
4maturity = "production"
5updated_date = "2026/03/30"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects when the ScreenConnect client (ConnectWise Control) connects to a newly observed host server that is not the official ScreenConnect cloud. ScreenConnect is a common RMM/remote access tool abused for C2 and persistence. Self-hosted or non-standard relay servers may indicate abuse or compromise. The rule aggregates by server host (parsed from the client command line), requires first-time observation within the rule window, and limits to a single host to reduce noise.
11"""
12from = "now-5d"
13interval = "6m"
14language = "esql"
15license = "Elastic License v2"
16name = "Newly Observed ScreenConnect Host Server"
17references = [
18 "https://attack.mitre.org/techniques/T1219/002/",
19 "https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-025a",
20]
21risk_score = 73
22rule_id = "a8b2c4d6-e8f0-12a4-b6c8-d0e2f4a6b8c0"
23severity = "high"
24tags = [
25 "Domain: Endpoint",
26 "OS: Windows",
27 "Use Case: Threat Detection",
28 "Tactic: Command and Control",
29 "Resources: Investigation Guide",
30 "Data Source: Elastic Defend"
31]
32timestamp_override = "event.ingested"
33type = "esql"
34
35query = '''
36from logs-endpoint.events.process-*
37| where event.category == "process" and event.type == "start" and (process.name == "ScreenConnect.ClientService.exe" or process.code_signature.subject_name == "ConnectWise, LLC")
38| grok process.command_line """e=Access&y=Guest&h=(?<Esql.screenconnect_server>[^&]+)&p"""
39| where Esql.screenconnect_server is not null and not Esql.screenconnect_server like "*.screenconnect.com"
40| stats Esql.count_distinct_host_id = count_distinct(host.id),
41 Esql.first_time_seen = min(@timestamp),
42 Esql.user_name_values = values(user.name),
43 Esql.command_line_values = values(process.command_line),
44 Esql.host_id_values = values(host.id),
45 Esql.host_name_values = values(host.name),
46 Esql.process_entity_id_values = values(process.entity_id) by Esql.screenconnect_server
47| eval Esql.recent = date_diff("minute", Esql.first_time_seen, now())
48| where Esql.recent <= 6 and Esql.count_distinct_host_id == 1
49| eval host.id = mv_first(Esql.host_id_values),
50 host.name = mv_first(Esql.host_name_values),
51 process.command_line = mv_first(Esql.command_line_values),
52 process.entity_id = mv_first(Esql.process_entity_id_values)
53| keep host.id, host.name, process.command_line, process.entity_id, Esql.screenconnect_server, Esql.user_name_values, Esql.first_time_seen
54'''
55
56note = """## Triage and analysis
57
58### Investigating Newly Observed ScreenConnect Host Server
59
60#### Possible investigation steps
61
62- What do the alert-preserved fields tell you about this new ScreenConnect relay?
63 - Focus: `Esql.screenconnect_server`, `Esql.user_name_values`, `Esql.first_time_seen`, `host.id`, `host.name`, and `process.command_line`; note `Esql.*` fields are alert-local, not source-event records.
64 - Implication: supports concern when the relay is an IP literal or unknown domain; weaker when it points to a recognized internal relay or managed service provider host.
65
66- Does the ScreenConnect client binary and install path match recognized software on this host?
67 - Focus: recover from source events via `process.entity_id`: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. $investigate_0
68 - Implication: suspicious when unsigned, portable, user-writable, or mismatched to its original file name; consistent only when signer and path match the expected ScreenConnect installation.
69
70- Does the parent and ancestry explain why this host initiated a new relay connection now?
71 - Focus: from the recovered source event: `process.parent.executable`, `process.parent.command_line`, `process.Ext.ancestry`, and `process.Ext.session_info.logon_type`.
72 - Implication: harder to justify when a script host, Office application, installer, or unexpected interactive session starts the client; easier to explain when the lineage resolves to a recognized service deployment or management tooling chain.
73
74- Do network events show the host contacting infrastructure consistent with the parsed relay?
75 - Why: `Esql.screenconnect_server` is an alert-level field, so source DNS and connection events are needed to confirm what the host actually contacted.
76 - Focus: DNS "lookup_result" events for `Esql.screenconnect_server` and connection events scoped to `process.entity_id` and `host.id`, checking `dns.question.name`, `dns.resolved_ip`, `destination.ip`, and `destination.as.organization.name`. $investigate_1
77 - Implication: supports concern when the process reaches public infrastructure with unknown ownership, or when multiple destinations cluster around the same relay; less concerning when the infrastructure matches the relay and belongs to a known hosting provider. Missing network telemetry is unresolved, not benign.
78
79- Does the host context fit managed service provider or internal ScreenConnect use?
80 - Focus: `host.id` and `Esql.user_name_values` pairing, and whether the same `Esql.screenconnect_server`, signer, and parent workflow recur across a known admin host group.
81 - Implication: more concerning if ScreenConnect appears on end-user or sensitive hosts not typically managed remotely, or if the user and host evidence do not fit the expected workflow; more explainable when the same managed host group, operator identity, and deployment pattern recur together.
82
83- Have other hosts in the environment resolved the same ScreenConnect relay domain?
84 - Focus: DNS events across all hosts where `dns.question.name` matches the relay from `Esql.screenconnect_server` over the last 30 days. $investigate_2
85 - Implication: multiple unrelated hosts resolving the same relay suggests a campaign or broad rollout; a single host stays locally bounded.
86
87- Does this host show related alerts or adjacent remote-access tooling that suggest broader compromise?
88 - Focus: related alerts for the same `host.id` in the last 48 hours, plus adjacent remote-access, persistence, credential-access, or delivery activity, especially renamed or portable ConnectWise or ScreenConnect binaries tied to the same relay. $investigate_3
89 - Implication: suggests broader host compromise when the asset also shows suspicious precursor delivery, persistence, credential theft, or additional remote-access tooling; stays locally bounded when the surrounding alert history is limited to expected admin activity or unrelated benign activity.
90
91- Escalate when the relay, client identity, launch lineage, contacted infrastructure, or host spread point to unauthorized remote access; close only when all evidence aligns with a recognized ScreenConnect workflow; if mixed or incomplete, preserve and escalate.
92
93### False positive analysis
94
95- Legitimate self-hosted ScreenConnect or managed service provider ConnectWise Control can trigger this rule. Confirm when the same `Esql.screenconnect_server`, recovered `process.executable`, signer, parent workflow, and DNS evidence all align with one recognized operator. If change records are unavailable, require the same client identity and admin host group to show prior new-relay alerts from this rule.
96- Before creating an exception, confirm the relay is authorized through organizational records, then build the exception on the relay domain in `process.command_line`. Avoid exceptions on `host.name` or `host.id` alone, since the rule fires per host and those would suppress only one endpoint.
97
98### Response and remediation
99
100- If confirmed benign, reverse any temporary containment and document the authorized relay, client signer and path, and source-event lineage. Build the exception on the relay domain in `process.command_line` once authorization is confirmed through organizational records.
101- If suspicious but unconfirmed, preserve the alert's `process.entity_id`, `process.command_line`, `Esql.screenconnect_server`, and any linked `dns.question.name` or `destination.ip` evidence. Apply reversible containment such as temporary DNS or egress blocking for the relay host. Escalate to host isolation only when the relay, lineage, or network evidence shows meaningful risk and the host's support role can tolerate it. Avoid destructive cleanup until scope is clearer.
102- If confirmed malicious, document the alert's `process.entity_id`, recovered `process.executable`, `process.code_signature.subject_name`, `process.command_line`, `Esql.screenconnect_server`, and any confirmed `dns.question.name` or `destination.ip` values before initiating response actions. Use available endpoint response integrations to isolate the host when the relay, client identity, lineage, or contacted infrastructure indicates unauthorized remote access. If direct endpoint response is unavailable, escalate with the documented artifacts to the team that can act.
103- Review how the software was installed, who operated the relay, and whether additional remote-access tooling or credential exposure is present on the host. Then block the malicious relay host and any confirmed relay IPs, and remove or disable the unauthorized ScreenConnect client, service, persistence mechanism, or installer artifacts identified during the investigation.
104- After containment, enforce approved-relay policy for remote-access tools and retain Elastic Defend process and network telemetry needed to validate future relay changes.
105"""
106
107setup = """## Setup
108
109This 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.
110
111Setup instructions: https://ela.st/install-elastic-defend
112"""
113
114[rule.investigation_fields]
115field_names = [
116 "host.id",
117 "host.name",
118 "process.command_line",
119 "Esql.screenconnect_server",
120 "Esql.user_name_values",
121 "Esql.first_time_seen",
122 "process.entity_id",
123]
124
125[[transform.investigate]]
126label = "Process events for the ScreenConnect client"
127description = ""
128providers = [
129 [
130 { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
131 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
132 { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
133 ]
134]
135relativeFrom = "now-1h"
136relativeTo = "now"
137
138[[transform.investigate]]
139label = "Network events for the ScreenConnect client"
140description = ""
141providers = [
142 [
143 { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
144 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
145 { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" }
146 ]
147]
148relativeFrom = "now-1h"
149relativeTo = "now"
150
151[[transform.investigate]]
152label = "Hosts resolving the same ScreenConnect relay domain"
153description = ""
154providers = [
155 [
156 { excluded = false, field = "dns.question.name", queryType = "phrase", value = "{{Esql.screenconnect_server}}", valueType = "string" }
157 ]
158]
159relativeFrom = "now-30d/d"
160relativeTo = "now"
161
162[[transform.investigate]]
163label = "Alerts associated with the host"
164description = ""
165providers = [
166 [
167 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
168 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
169 ]
170]
171relativeFrom = "now-48h/h"
172relativeTo = "now"
173
174[[rule.threat]]
175framework = "MITRE ATT&CK"
176[[rule.threat.technique]]
177id = "T1219"
178name = "Remote Access Tools"
179reference = "https://attack.mitre.org/techniques/T1219/"
180[[rule.threat.technique.subtechnique]]
181id = "T1219.002"
182name = "Remote Desktop Software"
183reference = "https://attack.mitre.org/techniques/T1219/002/"
184
185[rule.threat.tactic]
186id = "TA0011"
187name = "Command and Control"
188reference = "https://attack.mitre.org/tactics/TA0011/"
Triage and analysis
Investigating Newly Observed ScreenConnect Host Server
Possible investigation steps
-
What do the alert-preserved fields tell you about this new ScreenConnect relay?
- Focus:
Esql.screenconnect_server,Esql.user_name_values,Esql.first_time_seen,host.id,host.name, andprocess.command_line; noteEsql.*fields are alert-local, not source-event records. - Implication: supports concern when the relay is an IP literal or unknown domain; weaker when it points to a recognized internal relay or managed service provider host.
- Focus:
-
Does the ScreenConnect client binary and install path match recognized software on this host?
- Focus: recover from source events via
process.entity_id:process.executable,process.pe.original_file_name,process.code_signature.subject_name, andprocess.code_signature.trusted. $investigate_0 - Implication: suspicious when unsigned, portable, user-writable, or mismatched to its original file name; consistent only when signer and path match the expected ScreenConnect installation.
- Focus: recover from source events via
-
Does the parent and ancestry explain why this host initiated a new relay connection now?
- Focus: from the recovered source event:
process.parent.executable,process.parent.command_line,process.Ext.ancestry, andprocess.Ext.session_info.logon_type. - Implication: harder to justify when a script host, Office application, installer, or unexpected interactive session starts the client; easier to explain when the lineage resolves to a recognized service deployment or management tooling chain.
- Focus: from the recovered source event:
-
Do network events show the host contacting infrastructure consistent with the parsed relay?
- Why:
Esql.screenconnect_serveris an alert-level field, so source DNS and connection events are needed to confirm what the host actually contacted. - Focus: DNS "lookup_result" events for
Esql.screenconnect_serverand connection events scoped toprocess.entity_idandhost.id, checkingdns.question.name,dns.resolved_ip,destination.ip, anddestination.as.organization.name. $investigate_1 - Implication: supports concern when the process reaches public infrastructure with unknown ownership, or when multiple destinations cluster around the same relay; less concerning when the infrastructure matches the relay and belongs to a known hosting provider. Missing network telemetry is unresolved, not benign.
- Why:
-
Does the host context fit managed service provider or internal ScreenConnect use?
- Focus:
host.idandEsql.user_name_valuespairing, and whether the sameEsql.screenconnect_server, signer, and parent workflow recur across a known admin host group. - Implication: more concerning if ScreenConnect appears on end-user or sensitive hosts not typically managed remotely, or if the user and host evidence do not fit the expected workflow; more explainable when the same managed host group, operator identity, and deployment pattern recur together.
- Focus:
-
Have other hosts in the environment resolved the same ScreenConnect relay domain?
- Focus: DNS events across all hosts where
dns.question.namematches the relay fromEsql.screenconnect_serverover the last 30 days. $investigate_2 - Implication: multiple unrelated hosts resolving the same relay suggests a campaign or broad rollout; a single host stays locally bounded.
- Focus: DNS events across all hosts where
-
Does this host show related alerts or adjacent remote-access tooling that suggest broader compromise?
- Focus: related alerts for the same
host.idin the last 48 hours, plus adjacent remote-access, persistence, credential-access, or delivery activity, especially renamed or portable ConnectWise or ScreenConnect binaries tied to the same relay. $investigate_3 - Implication: suggests broader host compromise when the asset also shows suspicious precursor delivery, persistence, credential theft, or additional remote-access tooling; stays locally bounded when the surrounding alert history is limited to expected admin activity or unrelated benign activity.
- Focus: related alerts for the same
-
Escalate when the relay, client identity, launch lineage, contacted infrastructure, or host spread point to unauthorized remote access; close only when all evidence aligns with a recognized ScreenConnect workflow; if mixed or incomplete, preserve and escalate.
False positive analysis
- Legitimate self-hosted ScreenConnect or managed service provider ConnectWise Control can trigger this rule. Confirm when the same
Esql.screenconnect_server, recoveredprocess.executable, signer, parent workflow, and DNS evidence all align with one recognized operator. If change records are unavailable, require the same client identity and admin host group to show prior new-relay alerts from this rule. - Before creating an exception, confirm the relay is authorized through organizational records, then build the exception on the relay domain in
process.command_line. Avoid exceptions onhost.nameorhost.idalone, since the rule fires per host and those would suppress only one endpoint.
Response and remediation
- If confirmed benign, reverse any temporary containment and document the authorized relay, client signer and path, and source-event lineage. Build the exception on the relay domain in
process.command_lineonce authorization is confirmed through organizational records. - If suspicious but unconfirmed, preserve the alert's
process.entity_id,process.command_line,Esql.screenconnect_server, and any linkeddns.question.nameordestination.ipevidence. Apply reversible containment such as temporary DNS or egress blocking for the relay host. Escalate to host isolation only when the relay, lineage, or network evidence shows meaningful risk and the host's support role can tolerate it. Avoid destructive cleanup until scope is clearer. - If confirmed malicious, document the alert's
process.entity_id, recoveredprocess.executable,process.code_signature.subject_name,process.command_line,Esql.screenconnect_server, and any confirmeddns.question.nameordestination.ipvalues before initiating response actions. Use available endpoint response integrations to isolate the host when the relay, client identity, lineage, or contacted infrastructure indicates unauthorized remote access. If direct endpoint response is unavailable, escalate with the documented artifacts to the team that can act. - Review how the software was installed, who operated the relay, and whether additional remote-access tooling or credential exposure is present on the host. Then block the malicious relay host and any confirmed relay IPs, and remove or disable the unauthorized ScreenConnect client, service, persistence mechanism, or installer artifacts identified during the investigation.
- After containment, enforce approved-relay policy for remote-access tools and retain Elastic Defend process and network telemetry needed to validate future relay changes.
References
Related rules
- NetSupport Manager Execution from an Unusual Path
- Outlook Home Page Registry Modification
- Potential REMCOS Trojan Execution
- Potential Remote Desktop Tunneling Detected
- Network Activity to a Suspicious Top Level Domain