T1021.001: Remote Desktop Protocol
Adversaries may use Valid Accounts to log into a computer using the Remote Desktop Protocol (RDP). The adversary may then perform actions as the logged-on user.
Remote desktop is a common feature in operating systems. It allows a user to log into an interactive session with a system desktop graphical user interface on a remote system. Microsoft refers to its implementation of the Remote Desktop Protocol (RDP) as Remote Desktop Services (RDS).CitationTechNet Remote Desktop Services
Adversaries may connect to a remote system over RDP/RDS to expand access if the service is enabled and allows access to accounts with known credentials. Adversaries will likely use Credential Access techniques to acquire credentials to use with RDP. Adversaries may also use RDP in conjunction with the Accessibility Features or Terminal Services DLL for Persistence.CitationAlperovitch Malware
Security context for executives and security teams
RDP matters because it turns stolen or misused credentials into hands-on access to Windows systems. For leaders, this is a lateral-movement and resilience issue: if RDP is broadly enabled, weakly governed, or poorly logged, an intruder with valid accounts may move through the environment while appearing similar to normal remote administration.
Executive priority
Prioritize RDP governance where it protects critical Windows assets, privileged accounts, and incident response visibility. Executive questions should include: where is RDP enabled, who is allowed to use it, is MFA or equivalent access control applied where appropriate, are privileged RDP sessions auditable, and can the SOC distinguish expected administration from suspicious lateral movement? This technique is mapped by ATT&CK to multiple campaigns and groups, including ransomware and disruptive campaign contexts, so it should be treated as a control-validation priority rather than a purely technical setting.
Technical view
ATT&CK defines this as a Windows lateral-movement sub-technique under Remote Services: adversaries may use Valid Accounts to log into a computer through RDP/RDS and act as the logged-on user. ATT&CK provides no official detection text, but the related DET0327 strategy indicates a multi-event approach for RDP-based remote logins and post-access activity. SOC and IR teams should validate whether they can correlate successful remote logons, account context, source/destination systems, privilege level, and subsequent activity after the session. Because RDP can be legitimate administration, detection should focus on deviations from approved access paths and account use rather than RDP presence alone.
Likely telemetry
- Windows authentication and remote logon events for RDP/RDS sessions
- RDP/RDS session start, reconnect, disconnect, and logoff evidence where available
- Network flow or firewall records showing remote desktop connections between systems
- Account and group membership records supporting user and privileged account management
- Audit records for operating system configuration and enabled remote access services
Detection direction
- Do not rely on a single RDP connection event; validate multi-event correlation consistent with DET0327: remote login plus post-access activity.
- Baseline legitimate remote administration paths, accounts, and destination systems to reduce false positives.
- Prioritize anomalous use of valid accounts, especially privileged accounts, unexpected source systems, unusual destinations, or access outside normal administrative patterns.
- Confirm visibility on both the source and destination sides of RDP activity; network-only telemetry may not show whether the login was authorized or what occurred after access.
- Account for blind spots where RDP is enabled for operational reasons but logging, auditing, or account ownership is incomplete.
Mitigation priorities
- Start with user account management: ensure only accounts with a legitimate business requirement can use RDP.
- Apply privileged account management so administrative RDP access is limited, attributable, and monitored.
- Use MFA where appropriate for remote access paths and critical systems.
- Limit access to RDP over the network using approved access paths such as gateways, concentrators, ZTNA models, or equivalent controls where supported by the environment.
- Harden operating system configuration and disable or remove RDP/RDS where it is not required.
Additional notes and limits
This object is a sub-technique of T1021 Remote Services and replaces revoked T1076. The supplied relationships show multiple mitigations and a related detection strategy, but not detailed detection logic. Campaign and group relationships demonstrate that ATT&CK has observed this behavior across varied intrusion contexts; they should inform threat modeling, not assumptions of current exposure.
Official ATT&CK detection content is not provided for this object. The practical guidance above depends on local evidence: RDP enablement, account policy, MFA coverage, segmentation design, logging configuration, and normal administrative workflows. No claim is made that any organization has detection coverage or exposure without environment validation.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Remote Desktop Protocol
Adversaries may use Valid Accounts to log into a computer using the Remote Desktop Protocol (RDP). The adversary may then perform actions as the logged-on user.
Remote desktop is a common feature in operating systems. It allows a user to log into an interactive session with a system desktop graphical user interface on a remote system. Microsoft refers to its implementation of the Remote Desktop Protocol (RDP) as Remote Desktop Services (RDS).CitationTechNet Remote Desktop Services
Adversaries may connect to a remote system over RDP/RDS to expand access if the service is enabled and allows access to accounts with known credentials. Adversaries will likely use Credential Access techniques to acquire credentials to use with RDP. Adversaries may also use RDP in conjunction with the Accessibility Features or Terminal Services DLL for Persistence.CitationAlperovitch Malware
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.