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, and process.command_line; note Esql.* 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.
  • 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, and process.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.
  • 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, and process.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.
  • Do network events show the host contacting infrastructure consistent with the parsed relay?

    • Why: Esql.screenconnect_server is 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_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
    • 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.
  • Does the host context fit managed service provider or internal ScreenConnect use?

    • 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.
    • 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.
  • Have other hosts in the environment resolved the same ScreenConnect relay domain?

    • Focus: DNS events across all hosts where dns.question.name matches the relay from Esql.screenconnect_server over 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.
  • Does this host show related alerts or adjacent remote-access tooling that suggest broader compromise?

    • 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
    • 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.
  • 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, 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.
  • 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.

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_line once 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 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.
  • 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.
  • 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

to-top