RDP session takeover with tscon or session shadowing

Siemphony@siemphonymediumT1563+1unverified

Detects the two command-line forms of taking over an existing Windows remote desktop session: tscon.exe attaching another session to a terminal, and mstsc.exe shadowing a live session. tscon is matched on the binary alone because `tscon 2` with no further arguments already connects the target session to the caller's own — a complete hijack that a /dest: gate would miss, leaving only the longer variant that appears in write-ups. The shadow arm matches /shadow: on its own for the same reason: where the shadowing policy has already been set to view or control without consent, /noConsentPrompt is unnecessary and `mstsc /shadow:2 /control` takes the session silently, so a command line carrying both switches is the higher-confidence variant to triage first rather than the gate. Both are the observable MITRE's AN0216 describes as a session takeover with no matching logon event — the hijack produces no 4624 for the hijacker, which is why the logon events in the strategy cannot carry this detection on their own and the process creation source is used instead. The event says nothing about whose session was taken, so corroborate every hit with 4778 (session reconnected), 4779 (session disconnected) and 4624 with logon type 10 on the same host around the same time; the analytic's ExpectedUserSessionMap knob is the per-user baseline Sigma cannot hold. Classic tscon abuse runs as SYSTEM through a service the adversary created, so a parent of services.exe on a match is corroborating rather than exculpatory. Scope is the Windows RDP leg of DET0079 only, which is the mechanism ATT&CK files as T1563.002 — AN0217's Linux screen/tmux attach and PTY reuse and AN0218's macOS VNC and TTY takeover are not covered here. Where this is run against Security 4688 rather than Sysmon Event ID 1, Audit Process Creation and the separate "Include command line in process creation events" policy both have to be enabled or the shadow arm has no CommandLine to read and only the tscon arm survives. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0079, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 4 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Sentinel · KQL

Run this as a search.

DeviceProcessEvents| where (FolderPath endswith "\\tscon.exe" or (FolderPath endswith "\\mstsc.exe" and (ProcessCommandLine contains "-shadow:" or ProcessCommandLine contains "/shadow:" or ProcessCommandLine contains "–shadow:" or ProcessCommandLine contains "—shadow:" or ProcessCommandLine contains "―shadow:")))

Splunk · SPL

Run this as a search.

index=* (Image="*\\tscon.exe" OR (Image="*\\mstsc.exe" AND (CommandLine="*-shadow:*" OR CommandLine="*/shadow:*" OR CommandLine="*–shadow:*" OR CommandLine="*—shadow:*" OR CommandLine="*―shadow:*")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(process.executable) LIKE "*\\\\tscon.exe" OR (TO_LOWER(process.executable) LIKE "*\\\\mstsc.exe" AND (TO_LOWER(process.command_line) LIKE "*-shadow:*" OR TO_LOWER(process.command_line) LIKE "*/shadow:*" OR TO_LOWER(process.command_line) LIKE "*–shadow:*" OR TO_LOWER(process.command_line) LIKE "*—shadow:*" OR TO_LOWER(process.command_line) LIKE "*―shadow:*")))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,process_creation,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <!-- 2 rules: the Sigma condition ORs across different fields,       which one rule cannot express. Any one matching is a hit. -->  <rule id="100000" level="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="Image" type="pcre2">(?i)\\tscon\.exe$</field>    <description>RDP session takeover with tscon or session shadowing (1/2)</description>    <mitre>      <id>T1563</id>      <id>T1563.002</id>    </mitre>  </rule>   <rule id="100001" level="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="Image" type="pcre2">(?i)\\mstsc\.exe$</field>    <field name="CommandLine" type="pcre2">(?i)(-shadow:|/shadow:|–shadow:|—shadow:|―shadow:)</field>    <description>RDP session takeover with tscon or session shadowing (2/2)</description>    <mitre>      <id>T1563</id>      <id>T1563.002</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / windows
Level: medium
Category: lateral_movement_remote_exec
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: f339e12c-a958-4cf7-ba2b-21dcaaff90e9

ATT&CKT1563 +1

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessonlateral movement remote exec

lateral movement remote exec

01 · What this rule detects

Code executed on a remote host from another host inside the network — the step where an attacker moves from their initial foothold to a system that matters.

02 · Telemetry you need

Process creation with parent process on the destination host
Logon events with logon type, to distinguish network from interactive
Service creation events on the destination
Named pipe and SMB activity where available

03 · How the logic works

Remote execution shows up on the destination as a process whose parent is a service host, WMI provider, or the service control manager, combined with a network logon shortly before. Match the parent-child relationships that remote execution produces rather than the tool names — the parentage is a property of how Windows executes remote code and is much harder to avoid than a binary name. Correlating with the preceding logon gives you the source host and account, which is what an analyst needs first.

04 · Common false positives

Remote administration and patch management performing exactly this pattern by design
Monitoring agents that execute remote queries
Clustering and failover software coordinating across nodes
Vulnerability scanners with credentialed scanning enabled

05 · Detection maturity

Tier 1 — starting point: Matches known remote execution tool names.
Tier 2 — tuned: Matches the parent-child patterns remote execution produces, excluding management servers by source.
Tier 3 — correlated: Correlates with the preceding network logon and scores on whether that source-account-destination triple is normal.

Tuning & false positivesexperimental · 4 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

Exclude by source host rather than by tool — your management servers are a short, stable list
Direction matters: workstation to server is routine, server to workstation rarely is
Enrich with whether the source account normally authenticates to that destination
Administrative tooling used from an unusual source is the case worth alerting on

Declared by the author

Remote Desktop Connection Broker and Remote Desktop Session Host policy handling on an RDS farm, which reattach disconnected sessions programmatically on reconnect, session-limit and idle-timeout events; on any RDS deployment this is the highest-volume match by a wide margin and it carries no operator identity to triage against.
Terminal server administration. Moving a disconnected session back to the console with tscon is a documented recovery step, and an administrator reattaching their own session after a network drop produces the same event as a takeover of someone else's.
Help desk support tooling. Remote support and monitoring products wrap mstsc shadowing, and estates that have set the shadowing policy to no-consent for unattended servers will match on every support connection. Whether consent was possible is a policy question, not something this event answers.
Session brokers, kiosk and thin-client management scripts that reassign sessions on logoff or on a schedule, which call tscon as part of normal operation.

Noise check0 of 30 fired

Fires on none of the 30 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 30 behaviours, and the next ordinary behaviour nobody wrote down may still match.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification2 runs

Not verified

Security Datasets — RDP session hijacking
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.
Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1563, T1563.002, evaluated against their process_creation events.

Share this rule

/u/siemphony/f339e12c-a958-4cf7-ba2b-21dcaaff90e9

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

RDP session takeover with tscon or session shadowing

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it