---
{
  "title": "Remote Services",
  "summary": "Remote service abuse uses management or access services to reach another system.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    6
  ],
  "aliases": [
    "T1021"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1021: Remote Services",
      "url": "https://attack.mitre.org/techniques/T1021"
    }
  ],
  "editorialVersion": 2
}
---

## Normal administration can carry unauthorized access

Remote services allow an identity to access or manage another system through a supported interface. Administrators and users rely on these services for ordinary work. An actor controlling genuine credentials or another accepted access path can use the same functionality to reach additional resources.

A successful remote connection is not inherently malicious. The investigation should establish the source, destination, account, service, session, purpose, and subsequent actions. Network addresses or port numbers alone provide an incomplete explanation.

## A staff device reaches a server

In a fictional company, a privileged account establishes a remote session from a workstation that does not normally perform administration. The analyst reviews authentication and session records, source-device evidence, target processes, and the relevant maintenance schedule.

An emergency support task may explain the connection. Contact the responsible owner through a trusted channel and compare the actions with the approved purpose. A genuine account can still be under unauthorized control, so the account's existence does not settle the question.

The investigator separates failed authentication, successful session creation, command execution, and access to data. Each stage needs evidence appropriate to the service. A successful login does not prove that every accessible resource was used.

## Determine the actual access mechanism

[[exploitation-of-remote-services]] concerns a service vulnerability, while [[remote-service-session-hijacking]] concerns takeover of an existing session. This note focuses on using the remote service's normal access functionality. The corrective action depends on which path the evidence supports.

Review the identity's effective permissions and the network routes available. [[least-privilege]] and [[network-segmentation]] can reduce reach, but their actual configuration and enforcement must be verified.

Preserve identifiers and timestamps when correlating sources. Similar account names across domains or tenants are not automatically the same identity, and shared source addresses can obscure the originating device.

## Restrict unauthorized use without breaking support

Contain the affected account, session, or device as justified and review other resources reached through the same authority. Coordinate with service owners because blanket shutdown of remote management can impair both operations and incident recovery.

Verify that restrictions took effect and investigate how the actor obtained access. A password change may be one step, but active sessions, keys, or delegated access can require separate review under the platform's behavior.

For practice, compare an approved maintenance session with a fictional session from an unexplained workstation followed by new service creation. Identify identity, approval, session, process, and target-change evidence. [[lateral-movement]] provides the broader context, while [[incident-reporting]] keeps confirmed access distinct from potential reach and unproven downstream actions.

## Related concepts

- [[mitre-attack]]
- [[logs-and-telemetry]]
- [[incident-response]]
- [[valid-accounts]]
- [[software-deployment-tools]]