« Incoming DCOM Lateral Movement with MMC Execution via TSClient Mountpoint »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.24

Potential Remote Desktop Shadowing Activity

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Potential Remote Desktop Shadowing Activity

edit

Identifies the modification of the Remote Desktop Protocol (RDP) Shadow registry or the execution of processes indicative of an active RDP shadowing session. An adversary may abuse the RDP Shadowing feature to spy on or control other users active RDP sessions.

Rule type: eql

Rule indices:

  • logs-endpoint.events.process-*
  • logs-endpoint.events.registry-*
  • winlogbeat-*
  • logs-windows.sysmon_operational-*
  • endgame-*
  • logs-m365_defender.event-*
  • logs-sentinel_one_cloud_funnel.*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Lateral Movement
  • Data Source: Elastic Endgame
  • Data Source: Elastic Defend
  • Data Source: Sysmon
  • Data Source: Microsoft Defender XDR
  • Data Source: SentinelOne
  • Resources: Investigation Guide

Version: 316

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Potential Remote Desktop Shadowing Activity

Possible investigation steps

  • Which RDP shadowing path fired?
  • Focus: event.category, process.name, process.command_line, registry.path, registry.data.strings.
  • Implication: escalate faster for active "mstsc.exe /shadow" use or a Shadow policy value that removes consent; lower suspicion only when alert-local evidence matches recognized helpdesk, training, or policy-setting activity with consent retained.
  • Do process identity and lineage fit RDP shadowing components?
  • Focus: process.executable, process.pe.original_file_name, process.code_signature.subject_name, process.code_signature.trusted, process.parent.command_line.
  • Hint: for registry alerts, recover same-process starts for lineage or command-line detail. !{investigate{"description":"","label":"Process events for the same process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Implication: escalate when "mstsc.exe", "RdpSaUacHelper.exe", or "RdpSaProxy.exe" runs from a user-writable path, has an unexpected signer, or has a parent inconsistent with Remote Desktop Services or a support launcher. A trusted Microsoft binary confirms identity, not authorization.
  • If the Shadow registry value fired, did the new setting remove consent or allow control?
  • Focus: registry.path, registry.data.strings (decimal or hex: 1/0x00000001 = full control with consent, 2/0x00000002 = full control without consent, 3/0x00000003 = view only with consent, 4/0x00000004 = view only without consent), and process.executable.
  • Implication: escalate when registry.data.strings is 2/0x00000002 (full control, no consent) or 4/0x00000004 (view, no consent) because these allow silent shadowing; treat 1/0x00000001 or 3/0x00000003 as weaker setup evidence because the user is prompted, unless active shadowing or unexplained lineage appears.
  • If a process event fired, does it show active session shadowing?
  • Focus: process.name, process.command_line, process.parent.name, process.parent.executable.
  • Hint: if process.command_line is truncated or normalized, verify "/shadow", "/control", and "/noConsentPrompt" boundaries with process.args before lowering suspicion.
  • Implication: escalate when "mstsc.exe" includes "/shadow" with "/control" or "/noConsentPrompt". Treat "RdpSaUacHelper.exe" or "RdpSaProxy.exe" under a service host as active target-side shadowing that escalates when paired with no-consent/control, unexplained lineage, or unrecognized user-host context; a plain "mstsc.exe" launch without shadowing arguments is not enough.
  • Does user, host, and session context fit recognized support or training?
  • Focus: user.id, user.name, user.domain, host.id, process.Ext.session_info.logon_type.
  • Implication: escalate when user.id targets an unusual workstation, privileged session, or host with no matching shadow-support pattern; lower suspicion only when user-host pairing, session type, and branch evidence match the same recognized workflow.
  • Did the same actor prepare, persist, or extend the host-side shadowing activity?
  • Focus: user.id, process.entity_id, process.command_line, registry.path, registry.data.strings.
  • Hint: start with recovered same-process events; expand to same-host process and registry events only when local capability or context remains suspicious. !{investigate{"description":"","label":"Registry events on the host near the alert","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Implication: escalate when the same user or lineage enumerates sessions, prepares alternate-token launch, changes Terminal Services or RDP state, launches admin tooling, or persists shadow settings; absent process or registry evidence narrows the case but does not clear the alert.
  • If local findings stay suspicious or unresolved, do related alerts expand scope?
  • Focus: related alerts for the same user.id and host.id, especially remote-access, credential, remote-service, and persistence alerts.
  • Hint: review same-user alerts when local branch and capability questions remain suspicious. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • Hint: review same-host alerts when host preparation or follow-on activity remains unresolved. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • Implication: broaden scope when related alerts show the same user or host in remote-access, credential, or persistence activity; keep scope narrow only when local evidence fits a recognized workflow and related alerts do not contradict it.
  • Using branch, capability, identity, lineage, user-host fit, host-side activity, and related alerts, escalate unauthorized no-consent/control shadowing or stealthy policy relaxation; close only when evidence binds to one recognized support, training, or policy workflow with no contradictions; if mixed or incomplete, preserve process and registry artifacts and escalate.

False positive analysis

  • Helpdesk support, training labs, and supervised administration can legitimately use "mstsc.exe /shadow" or target-side "RdpSa*" helpers. Confirm process.command_line, process.name, process.parent.name, user.id, host.id, and any Shadow value align with the same authorized workflow, without contradictory process.command_line or registry.path evidence. Without ticketing or support rosters, require telemetry-only recurrence of the same command pattern, user-host pairing, consent mode, and quiet follow-on profile before closing as benign.
  • Group Policy or endpoint management tooling can legitimately change Shadow. Confirm stable process.executable, process.code_signature.subject_name, process.parent.command_line, exact registry.path, and resulting registry.data.strings match the host class. Without change records or GPO inventories, require quiet recurrence of the same process and registry pattern for the same management scope before closing.
  • Before creating an exception, anchor it on the minimum confirmed workflow: event.category, exact process.command_line or registry.path, registry.data.strings, user.id, and host.id. Avoid exceptions on process.name, registry.value, or Shadow alone.

Response and remediation

  • If confirmed benign, reverse temporary containment and document the exact event.category, process.command_line or registry.path, registry.data.strings, user.id, and host.id that proved the support, training, or policy workflow. Create an exception only after the same narrow pattern recurs.
  • If suspicious but unconfirmed, preserve a case export with the process tree, process.entity_id, process.command_line, process.parent.command_line, registry.path, registry.value, registry.data.strings, affected user.id, affected host.id, and surrounding preparation or follow-on evidence before changing host state.
  • Apply reversible containment next: restore the Shadow policy to the pre-change value, disable shadowing with 0, require consent with 1 or 3, or restrict the involved account on the affected host.id. Escalate to host isolation only when shadowing is part of broader session abuse and the host role can tolerate isolation.
  • If confirmed malicious, isolate the host when feasible, then terminate active "mstsc.exe" or "RdpSa*" shadowing processes after recording their process identifiers and command lines. Revert unauthorized Shadow and related Terminal Services or RDP shadow permission changes after preservation.
  • Scope other hosts and users tied to the same user.id, process.command_line, registry.path, or registry.data.strings before removing artifacts or resetting access.
  • Remove malicious helper scripts or tooling found during scoping, revert unauthorized RDP service or policy changes, and reset credentials that may have been exposed in the shadowed session.
  • Post-incident hardening: keep Shadow at the least permissive accepted setting, restrict who can shadow sessions, review RDP-Tcp shadow permissions, and retain process and registry telemetry needed to distinguish support use from no-consent shadowing.

Setup

edit

Setup

This rule is designed for data generated by Elastic Defend, which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

Rule query

edit
/* Identifies the modification of RDP Shadow registry or
  the execution of processes indicative of active shadow RDP session */

any where host.os.type == "windows" and
(
  (event.category == "registry" and event.type == "change" and
    registry.value : "Shadow" and
    registry.path : (
      "*\\Software\\Policies\\Microsoft\\Windows NT\\Terminal Services\\Shadow"
    ) and
    registry.data.strings : ("1", "0x00000001", "2", "0x00000002", "3", "0x00000003", "4", "0x00000004")

  ) or
  (event.category == "process" and event.type == "start" and
    (
      (process.name : ("RdpSaUacHelper.exe", "RdpSaProxy.exe") and process.parent.name : "svchost.exe") or
      (?process.pe.original_file_name : "mstsc.exe" and process.args : "/shadow:*")
    )
  )
)

Framework: MITRE ATT&CKTM

« Incoming DCOM Lateral Movement with MMC Execution via TSClient Mountpoint »