Detecting T1563 Remote service session hijacking

How T1563 remote service session hijacking shows up in lateral movement

For the SOC lead, the key point about T1563 is that an existing remote session changes hands. Under Lateral Movement (TA0008), an adversary who already controls one system uses T1563 to move onward by taking over a remote service session that a legitimate user or administrator established. The authentication event that would normally flag a new logon may never occur. ATT&CK describes two sub-techniques: SSH hijacking, where an existing SSH session is reused, and RDP hijacking, where an established Remote Desktop session is taken over. Both appear in intrusions where the adversary already has elevated access on a host, and they are most useful where sessions are long-lived, such as jump hosts, bastions and administrative workstations. These mappings target ATT&CK version 20.0, so confirm the sub-technique IDs against that release before you build rules.

The practical question is where long-lived sessions exist in your estate. Ask the platform team which SSH and RDP services allow multiple concurrent sessions, how idle sessions are kept alive and which accounts hold standing access to administrative hosts. Those answers determine what the telemetry will show. A hijacked session can appear as ordinary activity under a legitimate account, with no fresh logon to alert on, so detection has to correlate session continuity with the source host, the account and the processes started inside the session. An illustrative case: a service account that normally connects from one bastion suddenly drives an administrative shell from a workstation that has never used it. Decide now which of these hosts you will baseline first, and who in operations can confirm whether a given session should exist.

Plan the rehearsal around what you can already collect. ATT&CK links detection strategies for this technique to data components such as Logon Session Creation, Process Creation and Network Traffic Content, but whether you can see each one depends on your sensors and log forwarding, which you should confirm in your own environment. Because ATT&CK v18 replaced technique-level detections with detection strategies and analytics, map your rules to the DET IDs in the ATT&CK version you target and record that version alongside each rule. The mitre-attack/attack-stix-data repository publishes the STIX bundles you can use to check those mappings. Agree on the owner for the response path as well, since a suspected takeover usually needs an account reset and session termination before anyone can confirm scope.

Which telemetry reveals session hijacking on each platform

This table maps the data components most relevant to T1563 Remote Service Session Hijacking to the signal to look for, the open-source collector that gathers it, and the platform differences to confirm. Read each row as a source of evidence: no single source is sufficient, and the strongest detections correlate logon session events with network content and process activity on the same host.

Telemetry source	Signal to look for	Open-source collector and platform notes
Logon Session Creation (DC0067)	Session reuse or takeover on a host where the original session was not closed, or a new logon that does not match the user's usual source and time pattern	Wazuh agent on Windows reads security event logs; confirm which logon event types and session identifiers your build records. On Linux and macOS, confirm which authentication logs the agent forwards.
Network Traffic Content (DC0085)	Protocol content on remote service ports that shows a session continuing after an account or host change, with commands arriving from an unexpected source address	Zeek and Suricata on sensors at segment boundaries; confirm that the protocols you rely on, such as SSH or RDP, are parsed and that encrypted content is visible only as metadata.
Process Creation (DC0032)	Remote service child processes spawned under an inherited or unexpected session context, especially shells started by a service daemon	Wazuh agent or Velociraptor artifacts on Windows, Linux and macOS; confirm that command-line and parent process fields are captured on each platform, since Linux and macOS collection often differs.
Command Execution (DC0064)	Commands run through a remote session that do not match the normal administrative pattern for that host or account	Velociraptor hunts and Wazuh command monitoring; confirm whether your collector records command text or only process metadata, and how long it is retained.
Network Connection Creation (DC0082)	New or long-lived connections to remote service ports from hosts that do not usually initiate them	Zeek connection logs and Wazuh or Velociraptor network artifacts; confirm baseline peer lists before setting thresholds.
Platform differences	Windows exposes session identifiers through logon events, while Linux and macOS often rely on daemon logs and shell history	Confirm field names, retention and time synchronization for each platform in your own environment before writing correlation rules.

Detection logic for session hijacking that a SOC can tune

T1563 is hard to alert on because hijacked sessions reuse legitimate remote session activity. The cards below describe four detection ideas, each with the logic, the values to tune, the baseline to build and the benign sources that will trigger it first. Write each rule in Sigma and name the ATT&CK version it targets.

Session reuse from an unexpected host

Flag a remote logon session that appears on a second source host within a short window, or a session ID that is used from a host that never initiated it. The logic joins Logon Session Creation records with the source address and host name of the original logon. Tune the window and the allow list of known multi-hop paths. Build a baseline of which jump hosts and admin workstations legitimately carry sessions for each account. Expect help desk remote control tools and jump hosts to fire first, so allow-list them by host identity, not by IP alone. Keep the rule scoped to privileged accounts first.

Logon session attributes that change mid-session

Alert when attributes tied to a session, such as the source address, user agent, client name or elevation level, change during the session lifetime. Logon Session Creation and application logs usually record these fields at login, so the check compares later events against that first record. Tune the tolerance for legitimate roaming, VPN reconnects and NAT changes. Baseline how often each user's address changes in a normal working day. Common false positives come from VPN gateways that renew addresses, patch systems that reconnect after reboot and identity platforms that refresh tokens.

Unusual remote session tooling activity

Watch for remote session management utilities launched on hosts where they are not part of the approved admin toolset, or launched by accounts that do not normally use them. Process Creation and Command Execution telemetry give the parent process, binary path and invoking account. Tune by host role and by time of day. Build a baseline of which remote management tools each server group runs. Help desk tools, RMM agents and patch management consoles are the most common false positives, so document their expected parents and signed binaries before tuning.

Network content anomalies on administrative protocols

Inspect Network Traffic Content for administrative protocols such as SSH, RDP and WinRM, looking for session continuations that do not match a completed handshake from the same peer, or for administrative sessions that carry commands from a host with no logon record. Zeek and Suricata can record the session metadata that makes this comparison possible. Tune the expected session duration and the peer list per segment. Baseline normal administrative flows between jump hosts and servers. Patch scanners and monitoring agents that poll on fixed schedules will generate repeated, benign sessions.

How to confirm each T1563 detection fires before you trust it

This sequence turns each T1563 detection into a documented, repeatable test: an approved emulation, a recorded alert with its telemetry and timing, and a replay routine that proves the detection still works after every rule or logging change. The output is evidence that the detection fires, not an assumption that it does.

Get written approval from the asset owner
Before any test, the asset owner of each lab or range segment signs off on a written emulation scope. The scope names the hosts, accounts, network segments and Linux, macOS and Windows platforms in play, the T1563 sub-techniques under test, the test window and the people who can stop the test. Security operations and the owner of any production-adjacent system confirm they have read it. Done means a signed scope document is filed next to the detection record, and no emulation starts without it.
Document the benign behavior to emulate
The detection engineer writes a plain-language description of the behavior each detection targets, drawn from the ATT&CK technique and its sub-techniques for the version the rule maps to. The description states what the adversary would be doing at a conceptual level, which telemetry should reflect it, and which benign activity could look similar. It contains no commands, scripts or payloads. A second engineer reviews it. Done means a reviewed behavior statement exists for each detection under test.
Run the approved emulation in the cyber range
A tester who is not the rule author carries out the benign emulation inside the private range, following the agreed scope and the documented behavior statement. The tester logs the start and end time of each action and any deviation from plan. Production systems stay out of scope. Done means the emulation log, with timestamps, is complete and the tester confirms that every step ran as approved.
Record the alert, fields and time to alert
The analyst checks the SIEM, such as Wazuh or Security Onion, and records whether the expected alert fired, its rule identifier and severity, and the telemetry fields present in the event, such as process, logon session, network content or connection fields where the data component applies. The analyst also records the time between the first emulated action and the alert. Missing or empty fields are noted as findings. Done means a result record exists with alert status, field list and measured delay for each detection.
Log gaps and assign owners
The team compares the expected telemetry against what arrived and logs every gap, including sensors that did not forward events, fields that were dropped by parsing, and clock skew that distorted time to alert. Each gap gets a named owner and a fix target agreed with the asset owner. Done means a gap register is updated, and any detection that cannot be trusted is marked as such until its gap is closed.
Replay the test after every rule or logging change
Whenever a rule is tuned, a parser changes, a sensor is upgraded or the ATT&CK mapping moves to a new release, the team reruns the same approved emulation and compares the new results with the baseline record. A detection passes only if the alert still fires, the required fields still appear and the time to alert stays within the threshold the team set during the baseline run. Done means a pass or fail record is filed against the change ticket.
Close the loop with the asset owner
The detection engineer presents the results, gaps and replay history to the asset owner and security leads, and confirms which detections are trusted, which are conditional and which are retired. The asset owner signs the updated status. Any change that expands the emulation scope starts again at the approval step. Done means a signed status summary is stored with the detection record for the next review cycle.

Preventive controls that shrink the session hijacking surface

These controls reduce how often a remote session can be reused and how far it can travel. Each one removes an exposed service, narrows who can hold a privileged session, or makes a hijack visible in logs. Use them together with the detection work, since preventive gaps are what turn one hijacked session into a wider intrusion.

Disable or remove unused remote features

Disable or Remove Feature or Program (M1042) is the first mitigation to check for T1563. Session hijacking depends on a remote service that accepts and reuses an established session, so each installed remote management feature that nobody uses adds an exposed target. Inventory remote access services on every Linux, macOS and Windows host, remove those with no named owner or business need, and turn off session features on hosts that do not require them. Record each removal in change control so the baseline stays known and reviewable.

Limit privileged remote sessions

Privileged Account Management (M1026) limits how far a hijacked session can reach. When administrator accounts sign in remotely only from designated jump hosts, a session taken over on a workstation carries fewer useful privileges. Review which accounts open remote sessions, use time-bound elevation instead of standing rights, and require separate accounts for administration. Confirm that session timeouts and lockout behavior are enforced on those jump hosts, since they are the most valuable sessions to protect.

Audit remote session creation

Audit (M1047) does not stop a hijack, but it makes one visible. Enable logging for remote logons, session creation and privilege changes on every remote-access host, then forward those events to your SIEM, such as Wazuh. Without that baseline, the logon session creation and process creation telemetry used for detection has nothing reliable to correlate against. Check log retention and time synchronization on each source before relying on it during an investigation.

Segment administrative network paths

Network Segmentation (M1030) narrows which hosts can open remote sessions to each other at all. Place management interfaces on a dedicated network reachable only from approved jump hosts, and filter traffic between user and server zones. A hijacked session then has fewer routes to pivot through. Ask your network team to document the allowed flows, then test after each change that blocked flows stay blocked.

Confirm mappings for your ATT&CK version

Mitigation mappings change between ATT&CK releases, so tie every control to the version you target. This page uses Enterprise ATT&CK 20.0, released by MITRE on October 13, 2026, according to the attack-stix-data repository index. Pull the mapping from the STIX bundle for that version, compare it with the current technique page, and record the version in your control matrix. Revalidate after each release, since techniques can be renamed, deprecated or revoked.

What a SOC does when a session hijacking alert fires

The first decision on a T1563 alert is whether the session belongs to an authorized administrator performing planned work. Confirm ownership before anything is ended. Check the change calendar and the ticket queue for an approved maintenance window, then ask the administrator directly through a channel that does not depend on the session in question. Next, examine the source host and the account's recent history: which workstation or jump host the session originated from, whether that host is in the expected administrative zone, and whether the same account logged on from unusual locations or at unusual hours in the preceding days. Your Logon Session Creation and Process Creation records, collected by Wazuh or your EDR agent, should show whether the session was established normally and what the new session did after it opened. Compare what you find with the baseline for that account, not with a generic threshold.

If ownership cannot be confirmed, scope before you contain. Identify every other session on the same hosts, including sessions held by service accounts and sessions that share a source address, and review them against the same questions. Shared jump hosts and remote management endpoints deserve particular attention because one hijacked session there can reach many targets. Once scope is clear, contain by ending the suspect session and rotating the credentials of the affected privileged account, then confirm that the rotation has reached every system that trusts it. Preserve logs first: export the relevant Wazuh alerts, Zeek or Suricata network records and host telemetry to write-once storage with hashes and a documented chain of custody, so that later analysis does not depend on retention windows that may already be running.

Escalate to incident response when the session cannot be tied to an authorized administrator, when it touched more than one host, or when it preceded changes to privileged accounts, security tooling or logging configuration. Record each decision in the case file: the alert, the evidence reviewed, who confirmed ownership, the containment steps and their times, and whether the alert was true positive, benign administration or undetermined. Those records are the input for tuning. If benign administration triggered the rule, document the expected source hosts and accounts so the Sigma logic can exclude them narrowly, and review that exclusion each time the ATT&CK version your rules target changes. Ask your monitoring partner or internal team to confirm how long your retention settings keep the telemetry this triage needs.

Rehearsing T1563 detection and response in a private cyber range

This range models a set of Linux servers and macOS administrator workstations that reach each other over remote shell and management sessions. The topology should include at least one jump host, a set of server targets and a central log collector, with the telemetry pipeline kept separate from the systems under test. The benign inject schedule should include routine administrator logins, scheduled maintenance sessions and a few sessions that reconnect after a network interruption, so analysts learn what normal session reuse looks like before they see abnormal reuse. Telemetry that must arrive includes process creation events, network traffic content where the platform allows it, and session or logon records from the operating system. Good detection means an analyst can link a session reuse event to the originating user, host and process within the response window your team has set. Good response means the on-call analyst confirms the session owner, isolates the affected session, and records the decision in the case file. Set your own timing goals for acknowledgement, triage and containment, and confirm them against your staffing model.

Topology: Jump host, target servers and a collector, with the pipeline on its own network segment.
Benign inject schedule: Routine logins, maintenance sessions and reconnects after interruptions.
Required telemetry: Process creation, network content where supported, and session records.
Detection goal: Link each reuse event to a user, host and originating process.
Response goal: Confirm session ownership, contain the session and document the decision within team-set timing goals.

Check whether your platform logs session reuse as a distinct event on each Linux and macOS version in scope, because the record may differ from one release to the next.

Questions SOC leads ask about detecting session hijacking

How do SOC teams separate legitimate session reuse from session hijacking?

Start by defining what normal session reuse looks like in your environment, then alert on deviations from that pattern rather than on reuse alone. Legitimate reuse usually comes from a known account, a known source host or jump server, a predictable time window and a session that matches an earlier logon. Hijacking attempts tend to break one or more of those expectations, for example a session token used from a new host, a session that continues after the originating logon ended, or activity on a remote service that the account never used before. Correlate Logon Session Creation records with Network Traffic Content and Process Creation events, so a single anomaly can be checked against the other two. Confirm the thresholds with your identity team and with the owners of the remote services involved, because service accounts and automation often look suspicious to a generic rule.

Which log fields should you baseline first for session hijacking detection?

Baseline the fields that tie a session to an identity and a origin before anything else. In practice that means the account name, the logon type, the source address and host, the target service, and the time a session was created and last used. Process Creation and Network Traffic Content fields come next, because they show what the session did once it was open. Record these over a representative period that includes patch cycles, backups and admin work, since those events produce the most legitimate session churn. Store the baseline with the date range and the systems it covers, so that a later change in behavior can be traced to a configuration change or to a new tool. Review the baseline with the service owners before you turn any alert into a paging rule.

How do ATT&CK version changes affect session hijacking detection mappings?

Each ATT&CK release can rename, deprecate or revoke techniques and sub-techniques, and detection mappings can change with them. Record which ATT&CK version each rule and each coverage claim targets, and check that version against the MITRE update notes when you upgrade your tooling. ATT&CK v18 replaced detections in technique pages with detection strategies and analytics and changed data components, so older mappings may need to be re-expressed rather than copied forward. For T1563, confirm the current sub-technique list in the Enterprise STIX bundle for the version you target, and map each rule to the data component it actually uses. Keep a change log so auditors and your own team can see when a mapping moved and why.

How can you test session hijacking detections without affecting production?

Test in a private cyber range that mirrors your logging pipeline, identity configuration and remote services, but holds no production data or live credentials. Use a fixed test plan that lists each scenario, the expected telemetry, the expected alert and the owner who signs off on the result. Run the scenarios against the same log sources and parsers you use in production, so that a passing test proves the rule works on your data format, not just on a lab default. Schedule runs with the operations team, record the time and the systems involved, and remove test accounts and sessions afterward. DeployOpen runs private cyber ranges and security testing, and a rehearsal can be scoped in writing before work starts, so the boundaries of each exercise are agreed in advance.

What should you do when logon or network logs are missing during a hijacking investigation?

Treat missing telemetry as a finding in its own right, and do not assume that absence of an alert means absence of activity. First, identify which of the three core data components is missing: Logon Session Creation, Network Traffic Content or Process Creation. Then check whether the gap comes from an agent that stopped, a forwarding rule that changed, a log level that was lowered, or a retention limit that expired. Where possible, use a second source to fill the gap, such as domain controller records, network sensor data or endpoint artifacts collected by Velociraptor. Document the gap, the time window it affects and the compensating control you used, and note it in the investigation record. Close the gap in the logging pipeline, then rerun the rehearsal to confirm the detection works again.

Can our own team run session hijacking detection, or do we need outside help?

Your team can run the detection itself if it has the skills and time to own rules, log sources and tuning, and the skills are often the constraint. The work falls into a few areas: building the Wazuh or Security Onion pipeline, writing and testing rules, maintaining baselines, rehearsing scenarios and handling change when ATT&CK versions move. Outside help usually covers one or more of those areas on a fixed scope, such as implementing the pipeline, building the baseline, or running a range exercise and handing over the runbook. DeployOpen plans, implements and supports open-source platforms inside your own infrastructure, runs security testing and private cyber ranges, and offers ongoing support as a retainer. Ask any provider to name the deliverables, the owner of each rule, and what your team must maintain afterward.

How DeployOpen builds T1563 detections and range exercises

DeployOpen approaches T1563 Remote service session hijacking as a fixed-scope piece of work inside your own environment, covering the platforms and sub-techniques you agree in writing. Detection logic is built on open-source tooling and then rehearsed in a private cyber range before it is handed over.

How we scope

Agree in writing which operating systems, remote session services and log sources fall within the T1563 detection scope.
Confirm the ATT&CK version the detection mappings will target, since technique and sub-technique definitions can change between releases.
Record which telemetry is available today, such as process creation, logon session creation and network traffic content, and which gaps need closing.

How we build

Implement detection analytics in the open-source stack you run, such as Wazuh, Zeek, Suricata or Sigma rules, mapped to the relevant data components.
Tune rules against your normal administrative session patterns so that legitimate remote management activity is separated from suspicious takeover behavior.
Test detections in a private cyber range with scripted scenarios for each in-scope platform before anything reaches production.

How we hand over

Deliver written detection documentation that names each rule, its data source, its ATT&CK mapping and its known blind spots.
Provide range exercise runbooks so your analysts can repeat the validation and response steps without DeployOpen present.
Document the mitigations in scope, including Disable or Remove Feature or Program and Privileged Account Management, with the configuration evidence your team needs.

How we support

Ongoing support, rule upgrades and continuous testing are available as a retainer, and can be scoped alongside the original engagement.
Review detections when MITRE ATT&CK releases change T1563 or its sub-techniques, so mappings stay aligned with the version you target.
Confirm with your auditors or assessors which evidence they expect for detection and response controls, since DeployOpen prepares evidence but does not issue assessments.

T1563 Remote service session hijacking