Exploitation of Remote Services (MITRE ATT&CK T1210) is lateral movement through a software flaw. Once inside a network, an adversary exploits a programming error in a service, in an application, or in the operating system or kernel to run their own code on another machine. MITRE files it under Lateral Movement and lists ESXi, Linux, Windows and macOS as platforms.
It is the technique to think about when someone asks why internal patching matters if the perimeter is strong.
How attackers use it
A common goal is lateral movement: reaching a remote system from one that is already compromised. MITRE notes the attacker may first need to learn whether a remote system is in a vulnerable state. They may use network service discovery or other discovery methods that look for common vulnerable software, missing patches that hint at flaws, or security software that could detect or contain the exploit.
Servers are likely high-value targets, but endpoints can be at risk too if they give an advantage or access to more resources.
MITRE names well-known vulnerabilities in common services such as SMB and RDP, and in applications used inside networks such as MySQL and web server services. It also notes a number of vulnerabilities in VMware vCenter installations, which can let attackers move from a compromised vCenter server to virtual machines or even ESXi hypervisors.
Depending on the privileges of the vulnerable service, the attacker may also gain privilege escalation as a side effect.
The MITRE page lists several well-known worms and tools that used this approach, including malware that spread through victim networks with SMB exploits and one that used a Windows RPC vulnerability for remote code execution through a crafted request. The common lesson across them: an unpatched internal service is a path.
How to detect it
MITRE's detection strategy links network access to a service with signs that the service itself misbehaved.
Windows. Inbound access to remote service ports (SMB and RPC on 445 and 135, RDP on 3389, WinRM on 5985 and 5986), followed close in time by instability in the target service, such as a crash or abnormal restart, then suspicious child process creation under the service, then lateral movement behaviors. The chain suggests exploitation more than normal administration.
Linux. Inbound access to SSHD, SMB, NFS, databases or custom daemons, then a crash or restart of the daemon, a core dump, or a shell or reverse shell spawned from the service context.
ESXi and vCenter. Attempts to reach exploitable endpoints (OpenSLP on 427, CIM on 5989, hostd and vpxa HTTPS on 443, ESXi SOAP) combined with vmkernel or hostd crashes, unexpected restarts of hostd or vpxa, or new outbound or reverse connections from the ESXi host or vCenter to internal assets.
macOS. Inbound access to exposed services (ARD or VNC on 5900, SSH on 22, Screen Sharing, web services), process crashes in unified logs, and unusual child processes such as bash or curl under those services.
The pattern is the same everywhere. A service that has been quiet for months crashes, restarts and then starts a shell. Write one rule for each of your important services: alert when the service process creates a command interpreter.
Useful log sources:
- Windows event logs for service crashes (Application log) and process creation with parent process
- Linux auditd or EDR process events, and journald or syslog for daemon restarts
- Network flow data on internal east-west traffic to these ports
- Hypervisor and management server logs for hostd, vpxd and vpxa
How to reduce the risk
MITRE's mitigations:
- Isolate applications. Sandboxing and microsegmentation make it harder to advance through unknown or unpatched flaws.
- Disable or remove unneeded features. Keep available services to the ones that are necessary.
- Use exploit protection. Tools such as Windows Defender Exploit Guard and control flow integrity checking can stop some exploitation behavior, depending on compatibility with the target software.
- Segment the network. Limit access to critical systems and services to controlled paths.
- Limit service account permissions so that a compromised service can do less.
- Run a threat intelligence program to know which exploits and zero-days are likely to be used against an organization like yours.
- Patch internal endpoints and servers through patch management, not only the internet-facing ones.
- Scan the internal network regularly for available services, to find new and potentially vulnerable ones.
Check your own environment
- Do you have an inventory of the services listening on internal servers, not just external ones?
- Are SMB, RDP and WinRM reachable from every workstation, or only from the hosts that need it?
- What is your patch target for internal servers when a critical remote code execution flaw is published?
- Can a user workstation reach the management interface of your virtualization platform?
- Do service accounts run with domain or administrator rights?
- Do you alert when a server process starts a shell?
Two read-only checks. On Windows (PowerShell, run as administrator), this shows whether the old SMB version 1 protocol is enabled on the server:
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol
On Linux, this lists listening sockets and the owning process:
sudo ss -tulpn
Remove anything on that list that nobody can explain.
Quick check
What does MITRE suggest attackers do before exploiting a remote service?
They may run network service discovery or other discovery to find vulnerable software, missing patches or security software that could detect or contain the exploit.
Which sign separates exploitation from normal administration in the detection strategy?
Instability in the target service, such as a crash or abnormal restart, followed by suspicious child processes under the service.
Name two mitigations that limit the damage when a service is exploited.
Examples from MITRE: network segmentation, least-privilege service accounts, application isolation and sandboxing, and disabling unneeded services.
