T1021 Remote Services: Detecting and Containing Lateral Movement Over Admin Protocols

Once an attacker holds one valid credential, the remote administration protocols your teams use every day become the quickest route to every other system. MITRE ATT&CK technique T1021 Remote Services covers logons to services that accept remote connections, using accounts the attacker already has, then acting as that user. Because the traffic is legitimate RDP, SMB, WinRM, SSH or a cloud console session, signature tools rarely flag it. This guide is for detection engineers, Windows and Linux administrators and cloud platform teams who need log sources, detection logic and hardening that go beyond the ATT&CK entry, including the service accounts, keys and tokens that most often carry the movement.

Key takeaways

• T1021 is an identity problem on a network path. Every sub-technique starts with Valid Accounts (T1078), so the credential, not the protocol, is the thing to control and watch.
• Eight sub-techniques span on-premises and cloud. RDP, SMB admin shares, DCOM, SSH, VNC and WinRM sit alongside Cloud Services (T1021.007) and Direct Cloud VM Connections (T1021.008), which reach hosts through provider consoles rather than the network.
• Baseline who connects where. The strongest detections compare source, destination, account and logon type against a known admin pattern; a first-seen pair matters more than any single event.
• Remove credential exposure on the target. Remote Credential Guard, Restricted Admin mode, unique local administrator passwords and short-lived SSH certificates stop one compromised host from yielding the next credential.
• Machine identities move laterally too. Service accounts with network logon rights, deployment keys and cloud roles that can open sessions on VMs are frequently the widest paths and the least monitored.

How the attack works

ATT&CK describes the pattern simply: the adversary uses valid accounts to log into a service that accepts remote connections, then performs actions as the logged-on user. In a domain, one set of credentials may be accepted by hundreds of machines, and the same identity may also be federated to SaaS, IaaS and virtualisation management such as vCenter. The technique is therefore less about exploiting a protocol than about reusing access that already exists. For the wider tactic, see the Lateral Movement Guide; this page goes deep on the T1021 channels themselves.

A typical sequence has three parts, and each is a control point:

1. Obtain credential material: a password, NTLM hash, Kerberos ticket, SSH private key or cloud token, usually harvested from the first compromised host or bought from infostealer logs.
2. Reach a listening service: a port or management endpoint the account is allowed to use, or a cloud API that brokers a session to a VM.
3. Act as the user: run commands, copy tools (Lateral Tool Transfer, T1570), create services or scheduled tasks, or open an interactive desktop, then repeat from the new host.

The sub-techniques at a glance

Where it shows up

• Ransomware staging: operators commonly use SMB admin shares and remote service creation to push encryptors, and RDP to operate interactively. ATT&CK notes SSH being enabled on ESXi hosts directly or through vCenter before hypervisor encryption. See the ESXi Ransomware Playbook.
• Help desk and IT tooling: remote management products legitimately use these protocols, so attacker activity hides in the same noise. CISA advisory AA23-320A on Scattered Spider lists Remote Access Tools (T1219) alongside Cloud Services (T1021.007) for lateral movement and persistence.
• Cloud estates: a federated identity that reaches the cloud console can reach every VM the role allows. ATT&CK names Azure Serial Console, AWS EC2 Instance Connect and AWS Systems Manager as T1021.008 paths, which bypass network controls entirely because the provider brokers the session.
• Linux and DevOps: SSH keys copied between hosts, shared jump-box accounts and automation users with broad authorized_keys entries create trust chains an attacker can walk. See the SSH Key Management Guide.
• Data platforms: SaaS data services reached with a username and password are remote services too. In the Snowflake breach, attackers signed in to customer accounts with infostealer credentials through the web interface and command-line client, because the accounts had no MFA and no network allow lists.

Impact

T1021 turns a single foothold into estate-wide access. The direct consequences are privilege escalation (moving towards a host where a domain or cloud administrator has logged on), broad tool deployment, data collection from file servers and databases, and simultaneous encryption. In cloud estates the blast radius is set by role scope; a role that can open sessions on every instance in an account is equivalent to local root on all of them.

Detection

ATT&CK v20 links T1021 to detection strategy DET0269, a behavioural approach to remote service logons and post-access activity. In practice that means joining authentication events on the target with process and network events either side. For broader method, see the ATT&CK Detection Strategies and Analytics Guide.

Log sources to collect

Two field details trip teams up. Microsoft documents that Kerberos network logons typically carry no workstation name and that NTLM logons carry no TCP/IP details, so source attribution often needs the network or EDR record. AWS documents that Session Manager does not log session data for port forwarding or SSH tunnelled through it, because it acts only as a tunnel; if you rely on session logs, block or alert on those modes.

Detection logic that works

• First-seen source to destination pairs: alert when an account logs on with type 3 or type 10 to a host it has not used in the last 30 to 90 days, weighted up when 4672 (special privileges) follows on the same Logon ID.
• Workstation to workstation administration: admin logons where both source and destination are user endpoints rarely have a business reason in a tiered estate.
• Fan-out: one account or source host authenticating to many hosts in a short window, especially with share access to ADMIN$ or C$ followed by service creation.
• Remote execution children: wsmprovhost.exe, DCOM-launched mmc.exe or Office processes, or services created from admin share paths spawning shells or unsigned binaries.
• Service accounts used interactively: a service or automation account producing logon type 10, or SSH logons with a deployment key from a host outside its pipeline runners.
• Cloud session openers: session-opening API calls to production instances from identities that do not normally administer them, or EC2 Instance Connect use where it is meant to be disabled.

Metrics

• Percentage of servers and workstations forwarding 4624 and 5140 events to the SIEM.
• Number of accounts with standing remote logon rights to tier 0 systems, trending down.
• Share of RDP sessions to servers using Restricted Admin or Remote Credential Guard (from the Restricted Admin Mode field).
• Percentage of cloud VMs reachable only through a brokered, logged path (no public management ports).

Prevention and hardening

ATT&CK lists six mitigations for T1021: Limit Access to Resource Over Network (M1035), Audit (M1047), User Account Management (M1018), Disable or Remove Feature or Program (M1042), Multi-factor Authentication (M1032) and Password Policies (M1027). The table turns them into concrete settings.

For protocol-level depth see the Remote Desktop (RDP) Security Guide, the SMB Signing Guide, the Windows Remote Management and WinRM/PowerShell Remoting Security Guide and the OpenSSH Server Hardening Guide.

Rollout order

1. See it first: enable logon and share auditing on all servers and a pilot set of workstations, forward to the SIEM, and build a 30-day baseline of admin source and destination pairs.
2. Remove the cheap paths: deploy Windows LAPS, deny network and RDP logon for local accounts, and block workstation-to-workstation admin ports with host firewall rules in audit (log-only) mode for two weeks before enforcing.
3. Enforce credential protection: set the credential delegation policy on a pilot ring of admins; Microsoft documents that Remote Credential Guard works only with direct connections, not through RD Gateway or Connection Broker, and requires Kerberos, so test those paths before widening.
4. Broker cloud access: close public 22 and 3389, move to provider-brokered access with session logging, and restrict session-opening permissions to named roles.
5. Roll back safely: keep firewall and delegation changes in separate Group Policy objects or Intune profiles so either can be unlinked independently if a business application breaks.

Where identity fits

Machine identities often hold the broadest remote access. Backup and monitoring service accounts with network logon to every server, deployment SSH keys accepted on whole fleets, and cloud roles that can call session-opening APIs on any instance are all T1021 enablers. Treat them as privileged: give each a narrow logon scope, prefer gMSA for Windows services, replace static SSH keys with short-lived certificates, and alert whenever a machine identity authenticates from somewhere other than its expected host. AWS documents that an EC2 Instance Connect session persists after the pushed key's 60-second window and even after the caller's IAM credentials expire, so session duration limits matter as much as credential lifetime. See the Group Managed Service Accounts (gMSA) Guide and the MITRE ATT&CK T1078 Valid Accounts Guide.

Lessons from incidents

• Cloud remote services need the same controls as RDP: the Snowflake breach is a clear T1021.007 pattern. Credentials stolen by infostealers, in some cases years earlier and never rotated, were accepted by customer accounts without MFA or network allow lists. Rotation, MFA and source restrictions would each have broken the chain.
• Sanctioned tools are the cover: AA23-320A describes Scattered Spider using legitimate remote access software and cloud services for lateral movement, which is why CISA recommends allowlisting approved remote access tools and logging RDP login attempts.

Framework mapping

Practitioner checklist

• Collect 4624, 4625, 4648, 4672, 5140 and 5145 from every server, not only domain controllers, plus RDS operational logs.
• Build and maintain a baseline of administrative source and destination pairs; alert on first-seen pairs with privileged logons.
• Deploy Windows LAPS and deny remote logon for local accounts.
• Block admin ports between workstations; permit them only from jump hosts or privileged access workstations.
• Enforce "Restrict delegation of credentials to remote servers" for administrators after piloting.
• Scope every service account and automation key to the hosts it needs; alert on interactive use.
• Remove public management ports from cloud VMs and broker access with session logging; block untracked SSH tunnelling through session brokers.
• Require phishing-resistant MFA on RD Gateway, bastions, SSH and cloud consoles.
• Disable VNC, WinRM, serial console and ESXi SSH wherever they are not needed, and alert when they are enabled.

Standards and references

• MITRE ATT&CK: Remote Services (T1021)
• MITRE ATT&CK: Direct Cloud VM Connections (T1021.008)
• CISA: Scattered Spider advisory AA23-320A
• Microsoft Learn: 4624 An account was successfully logged on
• Microsoft Learn: Remote Credential Guard
• AWS: Logging session activity in Session Manager
• Google Cloud: Using IAP for TCP forwarding
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Lateral Movement Guide · T1133 External Remote Services Defensive Guide · MITRE ATT&CK T1078 Valid Accounts Guide · JIT Access Guide