Remote Services (T1021) is a lateral movement technique. Adversaries use valid accounts to log in to a service that accepts remote connections, such as telnet, SSH and VNC, and then act as the logged-on user. MITRE lists Linux, macOS, Windows, IaaS and ESXi.
The parent technique has sub-techniques for RDP, SMB and admin shares, distributed COM, SSH, VNC, Windows Remote Management, cloud services and direct cloud VM connections. Each has its own guide in this series.
How attackers use it
MITRE explains why this works in enterprise environments. Servers and workstations are organized into domains, which give central identity management so users log in with one set of credentials across the network. An adversary who obtains a valid set of domain credentials can log in to many machines over remote protocols such as SSH or RDP. They can also log in to SaaS or IaaS services that federate identity to the domain, or to management platforms for internal virtualization, such as VMware vCenter.
Legitimate applications also use remote services. Software deployment tools and administrative programs do. MITRE gives Apple Remote Desktop on macOS as an example. It combines protocols, including VNC for screen and control and SSH for secure file transfer, and adversaries can abuse it for remote code execution and lateral movement. MITRE adds that in macOS versions before 10.14, an adversary can escalate an SSH session to an ARD session, which allows them to accept TCC prompts without user interaction and reach protected data.
Nothing here is a vulnerability in the protocol. The problem is a valid credential in the wrong hands.
How to detect it
MITRE's detection strategy follows the login with what happens afterward:
- Windows: an RDP or WMI logon followed by uncommon command execution, file manipulation or lateral network connections.
- Linux: an SSH session from a new source address followed by an interactive shell or privilege escalation, such as sudo or su, and an outbound lateral connection.
- macOS: a remote login through ARD or SSH followed by screensharingd activity or changes to TCC-protected files.
- IaaS: use of a cloud bastion or VM console session followed by commands that start outbound SSH or RDP sessions to other environments.
- ESXi: vSphere API logins or SSH to the host followed by unauthorized shell commands or lateral remote logins from the host.
A login by itself is not suspicious, since people log in all day. A login that is new for that user, source or time, followed by a pattern of onward connections, is. Build a baseline of who normally logs on to what, then flag deviations.
Sources worth collecting:
- Authentication logs from Windows domain controllers and servers, Linux auth logs and cloud audit logs.
- Process creation and network connection events after the logon.
- Identity provider sign-in logs, since federated services use them.
How to reduce the risk
MITRE lists these mitigations:
- Limit Access to Resource Over Network: prevent unnecessary remote access to file shares, hypervisors and sensitive systems, using mechanisms such as network concentrators or RDP gateways.
- Audit: scan systems for weaknesses such as permissions, insecure software and configurations.
- User Account Management: limit which accounts can use remote services. For accounts at higher risk, limit permissions, for example by configuring SSH so users can only run specific programs.
- Disable or Remove Feature or Program: if remote services such as direct connections to cloud VMs are not needed, disable them. On ESXi, consider lockdown mode, which disables direct host access and requires management through vCenter.
- Multi-factor Authentication: use MFA on remote service logons where possible.
If you can only do two things, do MFA on every remote entry point and cut direct access so everything goes through a gateway you control.
Reading authentication logs with a baseline
The core job here is separating the usual logons from the unusual. Start by answering a few questions with your own logs:
- For each admin account, which hosts does it log on to in a normal month?
- For each server, which source networks do logons come from?
- Which hours do those logons happen in?
Those three lists become your baseline. A logon outside all three at once is a strong alert. A logon outside one is a note.
Splitting the work by platform
Windows and domain environments produce most of the volume, so start with domain controller and server logon events and add the remote interactive types. Linux gives you the auth log with source addresses and key or password method. Cloud and ESXi give audit trails of console, bastion and API logins. Send all of it into one place and make the account name consistent, so one person's activity is easy to follow across systems.
Think in paths
A single remote logon is a point. Lateral movement is a path: host A to host B to host C. The best use of the logs is to rebuild that path. When an alert fires on one host, look at where the account came from and where it went next. Flag accounts that appear on a new host within minutes of logging on to another, especially when the source host is a workstation.
Hardening that pays for itself
Some measures from MITRE's list also remove noise from your detections:
- Gateways. With a gateway in front of RDP, SSH or VNC, there is a single place to log, require MFA and cut off access.
- Fewer accounts. When only a short list of accounts can log on remotely, every other account doing it is an alert.
- Disabled services. A remote service that is off is a service no one can use, and a rule you do not need.
A note on ESXi and cloud
Virtualization management is a favorite place for lateral movement because one login reaches many machines. MITRE suggests lockdown mode for ESXi, so management goes through vCenter. Protect vCenter itself with MFA and with a short list of administrators. In the cloud, prefer managed access paths over direct inbound connections to virtual machines.
Check your own environment
On a Linux host, check which SSH settings are in effect (read-only, needs root on some systems):
sshd -T | grep -E "^(permitrootlogin|passwordauthentication|allowusers|allowgroups)"
Interpret the output:
- permitrootlogin should be no, or at least prohibit-password.
- passwordauthentication should be no wherever keys are practical.
- allowusers or allowgroups should name who may connect, rather than allowing everyone.
On Windows, check which ports are listening for remote access (read-only, PowerShell):
Get-NetTCPConnection -State Listen | Where-Object { $_.LocalPort -in 22,3389,5985,5986,5900 }
Questions for the team:
- Which systems accept remote logons from the whole network instead of from a gateway or management segment?
- Which accounts can log on remotely, and do they all use MFA?
- Which ESXi hosts run without lockdown mode?
- Do cloud VMs allow direct remote access from the internet?
Quick check
Why is a remote login alone a weak detection signal?
Valid users log in constantly. MITRE's strategy pairs a login with follow-on behavior such as uncommon commands, file changes, privilege escalation or onward lateral connections.
What does ESXi lockdown mode do?
It disables direct access to an ESXi host and requires the host to be managed remotely through vCenter, shrinking the number of ways in.
Which two controls give the most protection against this technique?
Multi-factor authentication on remote logons, and limiting network access so remote services are reachable only through gateways or management networks. Both come from MITRE's mitigation list.
