ScreenConnect Server Spawning Suspicious Processes

Identifies suspicious processes being spawned by the ScreenConnect server process (ScreenConnect.Service.exe). This activity may indicate exploitation activity or access to an existing web shell backdoor.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2024/03/26"
  3integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
  4maturity = "production"
  5updated_date = "2026/05/03"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies suspicious processes being spawned by the ScreenConnect server process (ScreenConnect.Service.exe). This
 11activity may indicate exploitation activity or access to an existing web shell backdoor.
 12"""
 13from = "now-9m"
 14index = [
 15    "endgame-*",
 16    "logs-crowdstrike.fdr*",
 17    "logs-endpoint.events.process-*",
 18    "logs-m365_defender.event-*",
 19    "logs-sentinel_one_cloud_funnel.*",
 20    "logs-system.security*",
 21    "logs-windows.forwarded*",
 22    "logs-windows.sysmon_operational-*",
 23    "winlogbeat-*",
 24]
 25language = "eql"
 26license = "Elastic License v2"
 27name = "ScreenConnect Server Spawning Suspicious Processes"
 28references = ["https://blackpointcyber.com/resources/blog/breaking-through-the-screen/"]
 29risk_score = 73
 30rule_id = "3d00feab-e203-4acc-a463-c3e15b7e9a73"
 31severity = "high"
 32tags = [
 33    "Domain: Endpoint",
 34    "OS: Windows",
 35    "Use Case: Threat Detection",
 36    "Tactic: Initial Access",
 37    "Data Source: Elastic Endgame",
 38    "Data Source: Elastic Defend",
 39    "Data Source: Sysmon",
 40    "Data Source: Windows Security Event Logs",
 41    "Data Source: Microsoft Defender XDR",
 42    "Data Source: SentinelOne",
 43    "Data Source: Crowdstrike",
 44    "Resources: Investigation Guide",
 45]
 46timestamp_override = "event.ingested"
 47type = "eql"
 48
 49query = '''
 50process where host.os.type == "windows" and event.type == "start" and
 51  process.parent.name : "ScreenConnect.Service.exe" and
 52  (process.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe", "csc.exe") or
 53  ?process.pe.original_file_name in ("Cmd.Exe", "PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE", "csc.exe"))
 54'''
 55
 56note = """## Triage and analysis
 57
 58### Investigating ScreenConnect Server Spawning Suspicious Processes
 59
 60#### Possible investigation steps
 61
 62- Does the alert prove ScreenConnect application-server execution rather than client-side remote command use?
 63  - Why: the reference separates server compromise from routine client deployment; server-side abuse uses "ScreenConnect.Service.exe", while client-side commands usually involve "ScreenConnect.ClientService.exe".
 64  - Focus: alert-local `process.parent.name`, `process.parent.executable`, `process.name`, `process.pe.original_file_name`, `host.id`, and `host.name`.
 65  - Implication: escalate sooner when "ScreenConnect.Service.exe" on the application server spawned "cmd.exe", PowerShell, or "csc.exe"; lower suspicion only when parent or host evidence proves this is not server-side execution, then resolve the mismatch before applying this guide.
 66
 67- Is the spawned child the genuine Windows tool expected by its name?
 68  - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
 69  - Implication: escalate when the child runs from a user-writable or ScreenConnect content path, is unsigned or untrusted, or PE metadata does not match the shell, PowerShell, or compiler name; confirmed identity says what ran, not that the launch is benign.
 70
 71- What intent is visible in the child command line and service context?
 72  - Why: ScreenConnect server exploitation often inherits the service identity, so SYSTEM or the expected service account does not reduce risk by itself.
 73  - Focus: `process.command_line`, `process.parent.command_line`, and `user.id`.
 74  - Implication: escalate when the command shows encoded PowerShell, download or staging, account creation, service changes, webshell-style shell use, or "csc.exe" compiling from temporary or ScreenConnect content paths; lower suspicion only for narrow maintenance, extension, or vendor-support action and later evidence agrees.
 75
 76- Do ScreenConnect server artifacts corroborate authentication bypass, extension traversal, or webshell staging?
 77  - Why: the reference describes CVE-2024-1709 admin-user changes in "Users.xml" and CVE-2024-1708 web-accessible ASP.NET content under "App_Extensions".
 78  - Focus: if file telemetry exists, query file events on `host.id` where `process.entity_id` equals server service `process.parent.entity_id`; if absent, pivot on `host.id`, service PID, and alert time, then review `file.path` and `file.name` for "Users.xml", "App_Extensions", ASP.NET files, or extension archives. $investigate_0
 79  - Hint: if file telemetry is unavailable or empty, inspect those server paths directly; missing file telemetry is unresolved, not benign.
 80  - Implication: escalate when "Users.xml" shows an unexpected admin, "App_Extensions" contains a lone ASP.NET file, or extension content appears outside GUID-scoped folders; lower suspicion only when artifacts stay inside expected extension paths and process evidence supports the same workflow.
 81
 82- Did the spawned child make network connections consistent with follow-on tooling or external control?
 83  - Focus: if network telemetry exists, query `host.id` and child `process.entity_id`; if absent, pivot on `host.id`, `process.pid`, and alert time, separating DNS `dns.question.name` from connection `destination.ip`, `destination.port`, and `destination.as.organization.name`. $investigate_1
 84  - Hint: Missing network telemetry is unresolved, not benign.
 85  - Implication: escalate when the shell, PowerShell, or compiler reaches a public destination with no ScreenConnect/vendor relationship, a staging domain, or any destination inconsistent with the recovered command; lower suspicion for absent destinations only after telemetry is verified and local process/artifact evidence resolve cleanly.
 86
 87- Do related host alerts change scope when local findings are suspicious or unresolved?
 88  - Focus: child process starts, additional children from the same ScreenConnect service parent, plus related alerts for `host.id`, especially webshell, persistence, credential-access, service-creation, or secondary-RMM alerts. $investigate_3
 89    $investigate_4
 90    $investigate_2
 91  - Implication: broaden response scope when the ScreenConnect server also shows exploitation, persistence, credential access, or secondary remote-access activity; keep scope local only when this alert is isolated and process, artifact, and destination evidence all resolve to one exact benign workflow.
 92
 93- Escalate when server-side parentage combines with suspicious child identity or command intent, or artifacts, destinations, or related alerts support compromise; close only when process evidence and recovery tie to one exact ScreenConnect maintenance, extension, or vendor-support workflow with no contradictions; preserve artifacts and escalate when evidence is mixed or visibility is incomplete.
 94
 95### False positive analysis
 96
 97- ScreenConnect server maintenance, extension installation, or vendor troubleshooting can legitimately spawn "powershell.exe", "cmd.exe", or "csc.exe". Confirm the same workflow across child identity, signer or hash, command intent, `host.id`, `user.id`, recovered server artifacts, and destinations when network telemetry exists. Use change records or vendor cases as corroboration, not a replacement for telemetry gaps.
 98- Do not treat generic administrative scripting or compile activity as benign on a ScreenConnect server. Confirm only narrow recurring service workflow: same parent path, child identity, command pattern, `user.id`, and quiet artifact or destination pattern on the same `host.id` across prior alerts or source events when external records are unavailable. One-off shells, downloaders, account changes, or root-level "App_Extensions" files remain suspicious.
 99- Before creating an exception, build it from the minimum confirmed workflow pattern: `process.parent.executable`, `process.executable`, a constrained `process.command_line` pattern, stable signer or hash, `host.id`, and the specific ScreenConnect maintenance or extension context. Avoid exceptions on `process.name` or "ScreenConnect.Service.exe" alone.
100
101### Response and remediation
102
103- Before restriction or cleanup in suspicious cases, preserve a case export of the alert process and parent records, recovered file and network events, ScreenConnect and IIS logs around the alert time, "Users.xml", the "App_Extensions" tree, suspicious extension archives or ASP.NET files, and staged payloads.
104- If confirmed benign, reverse temporary restrictions and document evidence proving the workflow: parent and child identity, command intent, server scope, expected ScreenConnect artifacts, and expected destinations if present. Build a narrow exception only after the same workflow recurs consistently.
105- If suspicious but unconfirmed, apply reversible containment tied to the findings: restrict public access to the ScreenConnect web interface, temporarily limit egress from the affected `host.id`, or suspend a newly created ScreenConnect admin account where operationally safe. Weigh server criticality before full host isolation.
106- If confirmed malicious, preserve the artifacts above before terminating processes or deleting files. Then isolate the server or disable public exposure, remove malicious admin accounts, webshells, extensions, secondary RMM services, and other persistence found during the investigation, and rotate compromised ScreenConnect, service, or domain credentials.
107- Patch ScreenConnect to a fixed version and review whether the attacker used the server to reach managed clients or create admin or service accounts.
108- After containment, retain process, file, and network telemetry needed for future ScreenConnect investigations, restrict who can manage extensions or internet exposure, and document any telemetry gaps that limited this investigation."""
109
110setup = """## Setup
111
112This 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.
113
114Setup instructions: https://ela.st/install-elastic-defend
115
116### Additional data sources
117
118This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
119
120- [CrowdStrike](https://ela.st/crowdstrike-integration)
121- [Microsoft Defender XDR](https://ela.st/m365-defender)
122- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
123- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
124- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
125"""
126
127[rule.investigation_fields]
128field_names = [
129    "@timestamp",
130    "host.name",
131    "host.id",
132    "user.id",
133    "process.entity_id",
134    "process.pid",
135    "process.executable",
136    "process.pe.original_file_name",
137    "process.command_line",
138    "process.parent.entity_id",
139    "process.parent.executable",
140    "process.parent.command_line",
141    "process.code_signature.subject_name",
142    "process.code_signature.trusted",
143    "process.hash.sha256",
144]
145
146[transform]
147
148[[transform.investigate]]
149label = "File events for the ScreenConnect server process"
150description = ""
151providers = [
152  [
153    { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
154    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
155    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.parent.entity_id}}", valueType = "string" }
156  ]
157]
158relativeFrom = "now-1h"
159relativeTo = "now"
160
161[[transform.investigate]]
162label = "Network events for the spawned child process"
163description = ""
164providers = [
165  [
166    { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" },
167    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
168    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
169  ]
170]
171relativeFrom = "now-1h"
172relativeTo = "now"
173
174[[transform.investigate]]
175label = "Alerts associated with the host"
176description = ""
177providers = [
178  [
179    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
180    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
181  ]
182]
183relativeFrom = "now-48h/h"
184relativeTo = "now"
185
186[[transform.investigate]]
187label = "Child process events from the suspicious child"
188description = ""
189providers = [
190  [
191    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
192    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
193    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
194  ]
195]
196relativeFrom = "now-1h"
197relativeTo = "now"
198
199[[transform.investigate]]
200label = "Process events from the same ScreenConnect service"
201description = ""
202providers = [
203  [
204    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
205    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
206    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.parent.entity_id}}", valueType = "string" }
207  ]
208]
209relativeFrom = "now-1h"
210relativeTo = "now"
211
212[[rule.threat]]
213framework = "MITRE ATT&CK"
214
215[[rule.threat.technique]]
216id = "T1190"
217name = "Exploit Public-Facing Application"
218reference = "https://attack.mitre.org/techniques/T1190/"
219
220[rule.threat.tactic]
221id = "TA0001"
222name = "Initial Access"
223reference = "https://attack.mitre.org/tactics/TA0001/"
224
225[[rule.threat]]
226framework = "MITRE ATT&CK"
227
228[[rule.threat.technique]]
229id = "T1059"
230name = "Command and Scripting Interpreter"
231reference = "https://attack.mitre.org/techniques/T1059/"
232
233[[rule.threat.technique.subtechnique]]
234id = "T1059.001"
235name = "PowerShell"
236reference = "https://attack.mitre.org/techniques/T1059/001/"
237
238[[rule.threat.technique.subtechnique]]
239id = "T1059.003"
240name = "Windows Command Shell"
241reference = "https://attack.mitre.org/techniques/T1059/003/"
242
243[rule.threat.tactic]
244id = "TA0002"
245name = "Execution"
246reference = "https://attack.mitre.org/tactics/TA0002/"
247
248[[rule.threat]]
249framework = "MITRE ATT&CK"
250
251[[rule.threat.technique]]
252id = "T1505"
253name = "Server Software Component"
254reference = "https://attack.mitre.org/techniques/T1505/"
255
256[[rule.threat.technique.subtechnique]]
257id = "T1505.003"
258name = "Web Shell"
259reference = "https://attack.mitre.org/techniques/T1505/003/"
260
261[rule.threat.tactic]
262id = "TA0003"
263name = "Persistence"
264reference = "https://attack.mitre.org/tactics/TA0003/"

Triage and analysis

Investigating ScreenConnect Server Spawning Suspicious Processes

Possible investigation steps

  • Does the alert prove ScreenConnect application-server execution rather than client-side remote command use?

    • Why: the reference separates server compromise from routine client deployment; server-side abuse uses "ScreenConnect.Service.exe", while client-side commands usually involve "ScreenConnect.ClientService.exe".
    • Focus: alert-local process.parent.name, process.parent.executable, process.name, process.pe.original_file_name, host.id, and host.name.
    • Implication: escalate sooner when "ScreenConnect.Service.exe" on the application server spawned "cmd.exe", PowerShell, or "csc.exe"; lower suspicion only when parent or host evidence proves this is not server-side execution, then resolve the mismatch before applying this guide.
  • Is the spawned child the genuine Windows tool expected by its name?

    • Focus: process.executable, process.hash.sha256, process.pe.original_file_name, process.code_signature.subject_name, and process.code_signature.trusted.
    • Implication: escalate when the child runs from a user-writable or ScreenConnect content path, is unsigned or untrusted, or PE metadata does not match the shell, PowerShell, or compiler name; confirmed identity says what ran, not that the launch is benign.
  • What intent is visible in the child command line and service context?

    • Why: ScreenConnect server exploitation often inherits the service identity, so SYSTEM or the expected service account does not reduce risk by itself.
    • Focus: process.command_line, process.parent.command_line, and user.id.
    • Implication: escalate when the command shows encoded PowerShell, download or staging, account creation, service changes, webshell-style shell use, or "csc.exe" compiling from temporary or ScreenConnect content paths; lower suspicion only for narrow maintenance, extension, or vendor-support action and later evidence agrees.
  • Do ScreenConnect server artifacts corroborate authentication bypass, extension traversal, or webshell staging?

    • Why: the reference describes CVE-2024-1709 admin-user changes in "Users.xml" and CVE-2024-1708 web-accessible ASP.NET content under "App_Extensions".
    • Focus: if file telemetry exists, query file events on host.id where process.entity_id equals server service process.parent.entity_id; if absent, pivot on host.id, service PID, and alert time, then review file.path and file.name for "Users.xml", "App_Extensions", ASP.NET files, or extension archives. $investigate_0
    • Hint: if file telemetry is unavailable or empty, inspect those server paths directly; missing file telemetry is unresolved, not benign.
    • Implication: escalate when "Users.xml" shows an unexpected admin, "App_Extensions" contains a lone ASP.NET file, or extension content appears outside GUID-scoped folders; lower suspicion only when artifacts stay inside expected extension paths and process evidence supports the same workflow.
  • Did the spawned child make network connections consistent with follow-on tooling or external control?

    • Focus: if network telemetry exists, query host.id and child process.entity_id; if absent, pivot on host.id, process.pid, and alert time, separating DNS dns.question.name from connection destination.ip, destination.port, and destination.as.organization.name. $investigate_1
    • Hint: Missing network telemetry is unresolved, not benign.
    • Implication: escalate when the shell, PowerShell, or compiler reaches a public destination with no ScreenConnect/vendor relationship, a staging domain, or any destination inconsistent with the recovered command; lower suspicion for absent destinations only after telemetry is verified and local process/artifact evidence resolve cleanly.
  • Do related host alerts change scope when local findings are suspicious or unresolved?

    • Focus: child process starts, additional children from the same ScreenConnect service parent, plus related alerts for host.id, especially webshell, persistence, credential-access, service-creation, or secondary-RMM alerts. $investigate_3 $investigate_4 $investigate_2
    • Implication: broaden response scope when the ScreenConnect server also shows exploitation, persistence, credential access, or secondary remote-access activity; keep scope local only when this alert is isolated and process, artifact, and destination evidence all resolve to one exact benign workflow.
  • Escalate when server-side parentage combines with suspicious child identity or command intent, or artifacts, destinations, or related alerts support compromise; close only when process evidence and recovery tie to one exact ScreenConnect maintenance, extension, or vendor-support workflow with no contradictions; preserve artifacts and escalate when evidence is mixed or visibility is incomplete.

False positive analysis

  • ScreenConnect server maintenance, extension installation, or vendor troubleshooting can legitimately spawn "powershell.exe", "cmd.exe", or "csc.exe". Confirm the same workflow across child identity, signer or hash, command intent, host.id, user.id, recovered server artifacts, and destinations when network telemetry exists. Use change records or vendor cases as corroboration, not a replacement for telemetry gaps.
  • Do not treat generic administrative scripting or compile activity as benign on a ScreenConnect server. Confirm only narrow recurring service workflow: same parent path, child identity, command pattern, user.id, and quiet artifact or destination pattern on the same host.id across prior alerts or source events when external records are unavailable. One-off shells, downloaders, account changes, or root-level "App_Extensions" files remain suspicious.
  • Before creating an exception, build it from the minimum confirmed workflow pattern: process.parent.executable, process.executable, a constrained process.command_line pattern, stable signer or hash, host.id, and the specific ScreenConnect maintenance or extension context. Avoid exceptions on process.name or "ScreenConnect.Service.exe" alone.

Response and remediation

  • Before restriction or cleanup in suspicious cases, preserve a case export of the alert process and parent records, recovered file and network events, ScreenConnect and IIS logs around the alert time, "Users.xml", the "App_Extensions" tree, suspicious extension archives or ASP.NET files, and staged payloads.
  • If confirmed benign, reverse temporary restrictions and document evidence proving the workflow: parent and child identity, command intent, server scope, expected ScreenConnect artifacts, and expected destinations if present. Build a narrow exception only after the same workflow recurs consistently.
  • If suspicious but unconfirmed, apply reversible containment tied to the findings: restrict public access to the ScreenConnect web interface, temporarily limit egress from the affected host.id, or suspend a newly created ScreenConnect admin account where operationally safe. Weigh server criticality before full host isolation.
  • If confirmed malicious, preserve the artifacts above before terminating processes or deleting files. Then isolate the server or disable public exposure, remove malicious admin accounts, webshells, extensions, secondary RMM services, and other persistence found during the investigation, and rotate compromised ScreenConnect, service, or domain credentials.
  • Patch ScreenConnect to a fixed version and review whether the attacker used the server to reach managed clients or create admin or service accounts.
  • After containment, retain process, file, and network telemetry needed for future ScreenConnect investigations, restrict who can manage extensions or internet exposure, and document any telemetry gaps that limited this investigation.

References

Related rules

to-top