Detecting T1021 remote services when attackers move through legitimate access paths
The SOC lead's hard question is not whether remote administration happens, but whether a given session is an approved administrator doing routine work or an adversary using the same protocols to move between systems. T1021 Remote Services sits under the Lateral Movement tactic (TA0008), where ATT&CK describes the adversary as trying to move through the environment. Here the adversary abuses remote access services that were built for administration, such as remote desktop, SSH, SMB-based administrative shares, remote management frameworks and cloud management interfaces, so the activity looks like normal operations on the wire. The technique spans 8 sub-techniques across Windows, Linux, macOS and IaaS platforms, and each one has its own telemetry and its own admin baseline. This page maps detections to ATT&CK version 20.0, so every detection mapping should name that version and be rechecked when a later release changes technique or sub-technique definitions.
Start by building an inventory of which accounts, source hosts, jump servers and service accounts are expected to use each remote protocol, and at what times. Logon Session Creation and Network Connection Creation telemetry from your endpoints and domain controllers will show who connected to what, and Process Creation telemetry will show which remote-management binaries ran on the target. Compare these against the inventory: a remote logon from a workstation that has never administered servers, a service account that suddenly authenticates interactively, or an administrative share written from an unexpected host are the deviations worth a ticket. Confirm with your identity and endpoint teams which of these sources you already collect, and at what retention, before you commit to a detection set.
Decide early which remote services you will restrict outright and which you will allow with monitoring. ATT&CK maps the mitigation Disable or Remove Feature or Program (M1042) and the mitigation Audit (M1047) to this technique, so the first decision is whether a protocol is needed in a given enclave at all, and the second is whether its use is logged well enough to reconstruct a session. Ask your platform team to confirm, for each in-scope platform, which remote services are enabled by default and which logging settings are required to capture session starts. Those answers determine whether the detections described in this page can work in your environment.
Which telemetry reveals remote service use and where it comes from
This table maps the five data components ATT&CK uses for T1021 detection to the signal each one exposes, the open-source collector that produces it, and the platform conditions that decide whether it exists at all. Read each row as a question: if this collector is not running on the host or segment, which detections go blind? The main takeaway is that most T1021 coverage depends on host logging being enabled before an incident, not on network tooling alone.
| Data component | Signal to look for | Open-source collector | Platform dependency and what to enable |
|---|---|---|---|
| Process Creation (DC0032) | Remote administration binaries or service tools launched by an unexpected parent or account, especially on servers that rarely run them | Wazuh agent on Windows and Linux, Sysmon on Windows, auditd on Linux | Windows needs process auditing with command line capture; Linux needs an audit rule set for execve calls. Neither is on by default in every build, so confirm it in each baseline. |
| Logon Session Creation (DC0067) | Network logons to administrative shares, remote desktop or SSH sessions from hosts that do not normally connect to that target | Wazuh agent collecting Windows Security and Linux authentication logs | Windows logon auditing must include success events for network logon types; Linux depends on sshd and PAM logging reaching the agent. Confirm retention on the manager. |
| Network Connection Creation (DC0082) | New inbound or outbound sessions on management ports such as SMB, RDP, WinRM or SSH between workstations, or between tiers that should not talk | Sysmon network connection events on Windows, auditd or Zeek connection logs on Linux and segment sensors | Host-level connection records depend on the sensor being installed on each endpoint. Zeek and Suricata see only traffic that crosses the sensor's tap or span point, so east-west coverage needs placement on the right segments. |
| Network Traffic Content (DC0085) | Protocol-level evidence of remote service sessions, such as authentication exchanges or service binding traffic on management protocols, where encryption does not hide the metadata | Zeek protocol analyzers and Suricata rules and protocol parsers at segment sensors | Content visibility ends where encryption begins. Many management sessions are encrypted end to end, so expect Zeek and Suricata to show session metadata more reliably than payload. Confirm which protocols are visible in your environment. |
| Command Execution (DC0064) | Remote commands or scripts run through a service on a target host, shortly after a network logon from another internal host | Velociraptor hunts and artifacts on endpoints, Wazuh active response logs, Sysmon or auditd command records | Command capture depends on the same process and command line auditing as Process Creation. Velociraptor needs an endpoint client on each host and enough disk and retention settings to keep the history you hunt against. |
Detection logic for remote logons, new remote sessions and unusual admin paths
The cards below describe detection ideas for T1021 Remote services that work from logon and network telemetry rather than from a single known-bad signature. Each idea compares a remote session against something the environment already knows about, such as a host pair, a time window, an account type or a normal number of hosts, so that alerts stay tied to a baseline you can tune.
Logons from unexpected source hosts
Build a per-account and per-server inventory of which source hosts normally open administrative protocol sessions such as RDP, SSH or WinRM. Alert when a logon of type network or remote interactive arrives from a source outside that inventory, and start with privileged accounts and domain controllers. Tune the baseline over several weeks, then review each alert against your asset inventory. Expected false positives come from jump hosts, patching consoles and remote support tools that legitimately reach many servers.
First-time host pairs
Record every source and destination host pair that has produced a remote logon, then flag pairs never seen before in the baseline window. A new pair is weak evidence alone, so raise its priority when the account is privileged or the destination holds sensitive data. Expected false positives come from new server builds, rotated load balancers and onboarding of contractors, so tie the alert to change records where you can.
Logons outside maintenance windows
Define the approved change and administration windows for each server tier, then alert on successful remote logons outside them. Because the window is your own policy, the threshold is a schedule rather than a statistic. Expected false positives come from on-call responders, time zone mismatches in logs and scheduled tasks that authenticate remotely, so normalize timestamps to UTC before comparing.
Bursts of logons across many hosts
Count distinct destination hosts reached by one account within a short sliding window, and alert when the count exceeds the account's own history. Set the window and count from observed behavior, starting high and lowering it as you confirm noise sources. Expected false positives come from patch management, backup agents, inventory scanners and configuration management runs, which touch many hosts in a predictable pattern.
Remote sessions from service accounts
Service and non-interactive accounts should rarely open interactive remote sessions. Alert on remote interactive logons and on network logons from these accounts when they originate from workstations or from hosts outside the service's documented path. Expected false positives come from scheduled jobs and monitoring agents that use network logons by design, so keep an allowlist of service-to-host pairs and review it on each change.
IaaS remote access from unusual identities
For cloud-hosted virtual machines, correlate control plane events that enable or open remote access, such as changes to network security rules or the creation of bastion or serial console sessions, with the identity that performed them. Alert when the identity is not in the approved operator group or the change falls outside a ticketed window. Confirm which events your cloud provider logs and at what detail before writing the rule. Expected false positives come from automation pipelines and break-glass procedures, which should be documented and labeled.
How to validate that a T1021 detection actually fires
This sequence proves, in a private cyber range, that each T1021 detection receives its telemetry, produces an alert with the expected fields, and stays tuned to the approved remote administration baseline. The output is a test record that a SOC lead and an auditor can both read.
Define the approved remote administration baseline
Before any test, the platform owner and the SOC lead write down which remote access paths are sanctioned for each platform in scope: Linux and macOS remote shells, Windows remote management, and IaaS management interfaces. For each path, record the approved source hosts, the service accounts or admin groups allowed to use it, and the expected hours or change windows. This baseline becomes the reference that separates an expected session from a suspicious one. The step is done when the baseline is reviewed and signed off by the people who own the remote access services, and the document names the ATT&CK version it targets (for example, the version your team mapped against).
Map scenarios to each sub-technique family
Using the sub-techniques of T1021 in the ATT&CK version you target, the team builds a scenario list with one or more representative remote access events per family in scope. Each scenario is described in plain words: which platform, which protocol family, which account type, and whether the source is an approved or unapproved host. The scenarios are reviewed by both the detection engineer and the red team lead so that they stay within the agreed rules of engagement. The step closes when every in-scope sub-technique family has at least one approved-path scenario and one deviation scenario, and the list is stored with the detection rules it exercises.
Run scenarios in the private cyber range
The red or purple team executes the scenarios only inside the private cyber range, against isolated hosts that mirror the production logging configuration. The operator records the start and end time of each scenario from a single time source so that later comparisons are accurate. Approved-path scenarios are run first to establish the expected pattern, followed by deviation scenarios. The step is complete when every scenario has a logged start and end time and the operator confirms in writing that nothing ran outside the agreed scope.
Confirm telemetry arrives in Wazuh or the SIEM
Before judging any alert, the detection engineer checks that the telemetry behind each scenario reached the platform. For T1021 this typically includes process creation, logon session creation and network connection creation events from the in-scope hosts, although the exact data components should be confirmed against the detection strategies for your ATT&CK version. The engineer checks ingestion delay, parsing of the source and target host fields, and whether any agent dropped or rate-limited events during the run. The step is done when every scenario has a matching set of raw events in Wazuh or the SIEM, and any gaps are logged as collection issues rather than detection failures.
Check alerts fire with the expected fields
For each scenario, the engineer compares the expected alert against the alert the platform produced. The check covers whether the rule fired at all, whether it fired once or repeatedly, and whether the alert carries the source host, target host, account, protocol context and timestamp needed for triage. Sigma rules or Wazuh rules that were converted for the platform are confirmed to contain the fields the analyst will pivot on. The step is complete when each scenario has a verdict of fired, not fired, or fired with missing fields, and each verdict is backed by a screenshot or exported alert record.
Record each test with timestamps and tuning changes
The team writes one test record per scenario containing the scenario ID, start and end timestamps, source and target hosts, the account used, the expected alert, the actual alert, and the verdict. Where a rule was adjusted, the record lists the change, the reason, and the scenario that prompted it, so that a later reviewer can see why the logic differs from the first version. Approved-path scenarios that produced alerts are also recorded, because a noisy baseline is a tuning problem that affects the SOC just as much as a missed detection. The step is done when the record set is stored in the change system and linked to the detection rule versions tested.
Retest after tuning and close the loop
After tuning, the team reruns the affected scenarios, including at least one approved-path scenario, to confirm the change fixed the gap without creating a new false positive pattern. Results are compared with the first run in the same record format. The SOC lead signs off on each detection as validated for the stated ATT&CK version, or lists it as open with an owner. The step closes when every in-scope detection has a dated, signed validation record, which is the evidence a compliance assessor or internal audit can review alongside the mitigation records for Audit and Disable or Remove Feature or Program.
Preventive controls that shrink the remote services attack surface
Remote services give an adversary a standard way to log on to another system once they hold valid access. Preventive controls reduce how many services and accounts can be used for that purpose, so detection has fewer paths to watch. The cards below pair each control with what it reduces and what to confirm in your own environment.
Disable unused remote services
Disable or Remove Feature or Program (M1042) is the ATT&CK mitigation for removing remote access features that the business does not need. On Linux, macOS and Windows hosts, check which remote logon services are listening, which ones are approved, and which are left enabled from old builds or default images. Confirm the list against your asset inventory, since a service nobody owns is the one nobody monitors.
Enable and review remote logon auditing
Audit (M1047) covers turning on the logging that makes remote logons visible: logon success and failure events, remote session starts and process activity on administrative hosts. Without this, Logon Session Creation and Process Creation data components have nothing to collect. Confirm that the audit policy is applied to every host class in scope, that events reach your central log platform, and that someone reviews the output on a defined schedule.
Restrict privileged account use
Privileged Account Management (M1026) limits which accounts can open remote sessions to sensitive systems. Most remote service abuse depends on reusing an administrative identity, so fewer standing privileged accounts means fewer logons that look legitimate. Confirm which accounts hold remote logon rights, whether they are time-bound or always on, and whether separate administrative identities are used for daily work.
Segment administrative network paths
Network Segmentation (M1030) restricts which hosts can reach remote service ports on other hosts. Limiting administrative protocols to jump hosts or management subnets turns many possible lateral paths into a short list that is easy to alert on. Confirm which subnets can reach remote logon ports across zones, and whether those rules are enforced by host firewalls as well as network devices.
Control user account lifecycle
User Account Management (M1018) governs how accounts are created, changed and removed. Stale or shared accounts with remote logon rights give an adversary valid credentials that look ordinary in logs. Confirm that dormant accounts are reviewed, that service accounts with remote rights have named owners, and that removal of leavers also removes remote access grants.
What a SOC should do when a remote service alert fires
The first decision in a T1021 alert is whether the remote logon is authorized. Start by matching the logon against an approved change, a scheduled administrative task or a known support session. Pull the source host, target host, account, logon type and time from the Logon Session Creation and Process Creation events, then check them against your change calendar and privileged access records. Confirm the source is a managed admin workstation or jump host and not a server, a user endpoint or an unfamiliar address. If the logon cannot be tied to an approved activity within the triage window agreed with your incident response team, treat it as suspicious and escalate.
Once the logon is in question, review the account and the path it used. Check the account's recent activity across hosts: other remote logons, new scheduled tasks or services, password changes, and failed attempts that preceded the success. Then scope the identity. Search the same account, and the source host, for other Network Connection Creation events on remote service ports during the same window, and list every target it touched. Compare that set with the account's normal footprint. Where your telemetry allows, confirm whether the target host shows related process activity such as remote command execution by a service account. Record every finding in the case with timestamps, because these records decide what containment is proportionate.
Containment should be staged and reversible where possible. For a confirmed or strongly suspected unauthorized session, disable or restrict the account at the directory, end the active session on the target and isolate the source host if it is compromised, after the incident commander approves the step. Escalate to the incident response team immediately if the account is privileged, if the source is a domain controller, or if more than one host shows the same pattern. Confirm with your identity team which service accounts can be disabled without breaking production jobs, and document that list before an incident, not during one.
Rehearsing T1021 detection in a private cyber range
A private range for Windows remote services should mirror the domain your organization runs: a small Active Directory forest with a domain controller, a file server, a management workstation and two or three user endpoints, all forwarding Windows event logs and Sysmon-style process telemetry to a Wazuh or Security Onion collector. Injects should exercise remote service logons over the management protocols your environment permits, along with a follow-on connection from an unexpected source host. Good detection means the Logon Session Creation and Process Creation events reach the SIEM within the agreed alert window, the alert carries the source host, account, logon type and parent process, and the asset inventory is joined so the analyst sees the owner and criticality without a manual lookup. Good response means the analyst opens a ticket with those fields filled in, disables the affected session through the agreed runbook, and hands off to the identity team with a timeline. Confirm the exact log channels and event IDs with your own platform configuration.
- Topology: separate the management segment from user segments so that remote service paths are explicit and testable.
- Injects: schedule remote logons from a non-administrative workstation at a set time, then a second hop from a server the account has no business reason to reach.
- Alert quality: check that the alert names the source, target, account and logon type, and that severity matches the asset criticality.
- Handoff: confirm the ticket reaches the on-call queue with the timeline attached and the correct owner assigned.
- Response: measure whether containment follows the runbook step order, not only whether an alert fired.
After each exercise, check that every alert was traceable to a logged event and that no detection depended on a single field that could be spoofed.
Linux and macOS hosts often accept remote access through SSH and similar services, and the rehearsal should cover both managed server fleets and a small group of developer or administrator Macs. The range should include a bastion host, two application servers, a build host and one macOS endpoint, with authentication logs and audit records shipped to the collector. Injects should use legitimate administrative access paths at unusual times, from unusual sources, and then a sequence of new connections between hosts that were not previously linked. Good detection means authentication events from the bastion are correlated with the destination host, the source address is enriched against the approved administrator list, and the analyst can distinguish a planned maintenance session from an unplanned one within the agreed time. Good response means the analyst revokes or rotates the affected keys or credentials under the runbook, isolates the host where needed, and records what was reviewed. Confirm which audit subsystems and log paths are available in your build, since these differ across distributions and macOS releases.
- Topology: place a bastion between user and server segments so every administrative path crosses one logged point.
- Injects: trigger a session from a host outside the administrator list, followed by a connection to a build server.
- Enrichment: confirm the alert includes the user, source address, key fingerprint or authentication method, and the change window status.
- Macs: test that endpoint telemetry from macOS hosts reaches the same case workflow as Linux events.
- Response: check that key rotation and host isolation are documented and timed against the runbook.
Review whether the detection still fires when the injected session uses a different account name for the same person, since identity mapping gaps are common in mixed fleets.
Remote services in cloud environments often appear as management-plane actions, such as a new instance session, a serial console connection or an identity token issued for a service principal, rather than as classic logons. The range should model a sandbox cloud account with a virtual network, a few instances, an identity provider integrated with the directory, and cloud audit logs forwarded to the collector. Injects should include a privileged identity used from an unexpected location, a remote session opened to a workload that has no recent change record, and a token reuse across two network zones. Good detection means the cloud audit event and the identity sign-in event are linked in one case, the alert reflects the difference between a routine administrator action and an unusual one, and the enrichment includes the tenant, subscription or project, and the change ticket reference. Good response means the analyst revokes sessions and tokens through the identity platform, reviews the affected role assignments, and documents evidence in a form the cloud team can act on. Confirm which audit and sign-in log categories your provider exposes and how long they are retained in your account.
- Topology: use a dedicated sandbox account or project with the same identity integration as production, but no production data.
- Injects: schedule a privileged sign-in from an unusual network, then a remote session to a workload without a matching change record.
- Correlation: check that identity and control-plane events share a session or correlation identifier that the analyst can pivot on.
- Containment: test token revocation and role review, and confirm that the cloud team receives a clear list of affected resources.
- Evidence: verify that the exercise record shows timestamps, decisions and the ticket trail for later review.
Confirm that exercise accounts and credentials are isolated from production and that all rehearsal artifacts are removed or archived at the end of each run.
Common questions from SOC leads and detection engineers on T1021
How do we baseline remote administration without blinding our admins?
Start by inventorying which accounts, source hosts and jump paths legitimately use SSH, RDP, WinRM and other remote services, then alert on deviations from that baseline rather than on the protocol itself. Build the baseline from logon session creation and network connection records over a period long enough to include patch windows and on-call rotations. Tag known administrative workstations and service accounts, and review the allowlist with the administrators who own those paths. Alerts should cover new source-to-target pairs, logons outside approved change windows, and remote service use by accounts that have never used it. Confirm your retention window covers the baseline period before you tune anything.
How should we handle jump hosts and privileged access management tools in detections?
Treat the jump host and the privileged access management (PAM) broker as known, high-value pivot points that must be monitored more closely, not exempted. Log sessions that enter and leave the broker, and correlate them with the target logons they create, so an administrator's approved session is distinguishable from a logon that bypasses the broker. Alert when a remote service logon to a sensitive host does not originate from the PAM tool or an approved jump host. Confirm with your PAM vendor which session and audit records it exports and in what format, because not every product forwards per-session detail to a SIEM by default.
Do Zeek or Suricata add value over host logs for T1021 detection?
Yes, for coverage, but they complement host telemetry rather than replace it. Host logs show which account authenticated and what process ran after the logon, while network sensors such as Zeek and Suricata show which hosts spoke to which remote service ports, including traffic from hosts that lack a managed agent. Zeek connection and protocol logs, for example, can reveal SSH or RDP sessions between segments that your endpoint sources never report. Test that your sensors actually see east-west traffic, because a sensor placed only at the internet edge will miss most lateral movement. Confirm the sensor placement and the protocol parsers enabled in your version before relying on them.
How do we version our T1021 mappings against ATT&CK 20.0?
Record the ATT&CK version in every detection rule's metadata, and pin mappings to the enterprise-attack 20.0 STIX bundle you tested against. ATT&CK publishes content in STIX 2.1 in the attack-stix-data repository, and releases can rename, deprecate or revoke techniques and sub-techniques. Since ATT&CK v18, detections are expressed as detection strategies and analytics identified by DET IDs, and data components use DC IDs, so older mappings to data sources may need rework. Keep a changelog that lists which DET and DC IDs each rule uses, and diff the new bundle against your previous one at each release to find affected rules.
How often should we rerun validation after tuning detections?
Rerun the relevant validation after every tuning change, after each ATT&CK version update, and after significant changes to remote access paths, such as a new jump host or a changed PAM product. Beyond those triggers, schedule a recurring run that replays a fixed set of remote service scenarios in your cyber range and confirms the expected alerts still fire. The right cadence depends on how often your environment and rules change, so agree it with your detection engineering lead and record it in your change process. Keep the results as evidence so you can show when each alert was last proven to work.
Can our own team run these detections, or do we need outside help?
Your team can run them if it already operates a SIEM, has access to host and network telemetry, and has time to maintain rules. The work breaks into building the baseline, writing and tuning rules, validating them in a range, and running the response playbooks, and each part needs ownership by a named person. Outside help is most useful for scoping the work, standing up the open-source stack inside your own environment, or rehearsing detection in a private cyber range. DeployOpen plans, implements and documents self-hosted platforms in the client's own infrastructure and runs cyber range exercises, and the scope is agreed in writing before work starts. Ask any provider which parts they will hand over to your team.
What drives the cost of rehearsing T1021 detection in a cyber range?
The main drivers are the number of environments you need to simulate, such as Linux, Windows and cloud hosts, how many remote services and sub-techniques you cover, and how often you repeat the exercise. One-time costs include designing the range topology, building the telemetry pipeline and writing the exercise scenarios. Recurring costs include rerunning validation after tuning or ATT&CK updates, and reviewing findings with the response team. Ask for a quote that lists these components separately, states what is handed over at the end, and identifies which parts recur. No public figure for these costs is supplied here, so confirm pricing against your written scope.
How DeployOpen builds T1021 detections and range exercises
DeployOpen works on T1021 Remote Services as a fixed-scope engagement inside the client's own infrastructure, covering the platforms and telemetry the client agrees to in writing. The work moves from agreed scope to tested detections, documented runbooks and a private cyber range rehearsal that the client's team can repeat.
How we scope
- Agree in writing which T1021 sub-techniques and platforms are in scope, such as Linux, macOS, Windows and IaaS.
- Inventory which remote service logs (logon, process and network connection) the client already collects and where they are stored.
- Confirm the ATT&CK version the detection mappings will target, so later releases do not silently change the coverage.
How we build
- Write detection logic for Process Creation, Logon Session Creation and Network Connection Creation telemetry in Sigma format.
- Deploy and tune rules in the client's Wazuh or Security Onion stack, using the client's own hosts and remote access paths.
- Map each rule to its ATT&CK detection strategy and the audit and disable-feature mitigations the client has in place.
How we hand over
- Deliver the rule set, mapping tables and tuning notes in a form the client's security engineers can maintain.
- Provide response runbooks for suspected remote service misuse, including evidence collection and escalation steps.
- Run a private cyber range exercise with the client's team and record which detections fired, missed or needed tuning.
How we support
- Support ongoing tuning and rule updates as ATT&CK releases change techniques, sub-techniques or detection strategies.
- Offer retainers for continuous testing and periodic cyber range rehearsals, agreed separately from the initial scope.
- Ask for a written quote based on the defined scope, which sets out what is one-time work and what recurs.
