MITRE ATT&CK® Technique

T1505.005: Terminal Services DLL

Adversaries may abuse components of Terminal Services to enable persistent access to systems. Microsoft Terminal Services, renamed to Remote Desktop Services in some Windows Server OSs as of 2022, enable remote terminal connections to hosts. Terminal Services allows servers to transmit a full, interactive, graphical user interface to clients via RDP.[1]

Windows Services that are run as a "generic" process (ex: svchost.exe) load the service's DLL file, the location of which is stored in a Registry entry named ServiceDll.[2] The termsrv.dll file, typically stored in `%SystemRoot%\System32\`, is the default ServiceDll value for Terminal Services in `HKLM\System\CurrentControlSet\services\TermService\Parameters\`.

Adversaries may modify and/or replace the Terminal Services DLL to enable persistent access to victimized hosts.[3] Modifications to this DLL could be done to execute arbitrary payloads (while also potentially preserving normal termsrv.dll functionality) as well as to simply enable abusable features of Terminal Services. For example, an adversary may enable features such as concurrent Remote Desktop Protocol sessions by either patching the termsrv.dll file or modifying the ServiceDll value to point to a DLL that provides increased RDP functionality.[4][5] On a non-server Windows OS this increased functionality may also enable an adversary to avoid Terminal Services prompts that warn/log out users of a system when a new RDP session is created.

EnterpriseT1505.005Sub-techniqueObject v1.0 Modified Oct 24, 2025, 17:48 UTC (UTC+00:00)

Discuss defensive coverage Back to ATT&CK

Terminal Services DLL abuse is a Windows persistence concern around Remote Desktop Services. If an attacker can alter the Terminal Services service DLL configuration or replace/modify the DLL it loads, remote access behavior may be changed in a way that survives reboot and blends into a legitimate Windows service path. For leaders, the issue is not just RDP exposure; it is whether critical Windows systems have enough registry, file integrity, and RDP session visibility to prove that remote access components have not been tampered with.

Executive priority

Prioritize this where Windows hosts support administration, remote operations, or sensitive business services. The business decision is whether remote access infrastructure is governed as a high-value control surface: restricted change rights, auditable configuration baselines, and incident response evidence for unexpected RDP behavior. This technique also supports compliance readiness because teams may need to demonstrate that sensitive registry keys, service DLL paths, and remote access components are monitored and reviewed.

Technical view

This is a Windows persistence sub-technique under Server Software Component. Validate the TermService configuration, especially the ServiceDll value under HKLM\System\CurrentControlSet\services\TermService\Parameters\, and confirm expected use of %SystemRoot%\System32\termsrv.dll. SOC and IR teams should look for unauthorized registry modification, replacement or patching of termsrv.dll, and RDP behavior inconsistent with host role or policy. Official ATT&CK detection text is not provided, but the relationship to DET0212 indicates a detection strategy exists for Terminal Services DLL modification; use it as a validation reference if available locally.

Likely telemetry

Windows registry auditing for TermService\Parameters and ServiceDll changes
File integrity or endpoint telemetry for termsrv.dll in %SystemRoot%\System32\
Windows service configuration and service load telemetry for TermService
RDP session and logon evidence, including unexpected concurrent or interactive remote sessions
Change management records for approved Remote Desktop Services configuration changes

Detection direction

Baseline the expected ServiceDll path and hash/state of termsrv.dll on supported Windows builds, then alert on deviation.
Correlate registry changes to TermService parameters with process, user, host role, and approved maintenance windows.
Treat RDP session anomalies as supporting context, not standalone proof, because legitimate administration can create similar activity.
Tune for known administrative or compatibility tools only where explicitly approved; unapproved changes to Terminal Services functionality should remain high-signal.
Account for the blind spot that ATT&CK provides no official detection narrative here, so local event coverage and DET0212 implementation details must be verified.

Mitigation priorities

Restrict registry permissions on sensitive service configuration keys, consistent with M1024.
Use auditing, consistent with M1047, to record and review service configuration, registry, file integrity, and RDP access evidence.
Limit who can change Remote Desktop Services configuration and require change control for approved modifications.
Maintain trusted baselines for Terminal Services DLL location and integrity on Windows systems.
Include Terminal Services DLL checks in incident response triage for Windows hosts with suspicious RDP activity or unexplained persistence.

Analyst notes and limits

The most material defender question is whether the organization can distinguish an approved Remote Desktop Services configuration from an unauthorized persistence change. This technique is especially relevant when RDP is operationally necessary, because adversary changes may hide behind legitimate remote administration workflows.

The supplied ATT&CK object does not include official detection text, procedure examples, impact claims, or attribution. This take is limited to the Windows platform, persistence tactic, cited Terminal Services behavior, and listed relationships. Local host baselines, audit policy, and change records are required to determine exposure or detection coverage.

Official MITRE ATT&CK definition

Terminal Services DLL

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

Filter related techniques 1 rows

Domain	ID	Name	Relationship / procedure
Enterprise	T1505	Server Software Component	This object subtechnique of Server Software Component.

Relationship explorer

All related ATT&CK context

mitigates · Mitigation M1047: Audit Enterprise detects · Detection Strategy DET0212: Detection Strategy for T1505.005 – Terminal Services DLL Modification (Windows) Enterprise mitigates · Mitigation M1024: Restrict Registry Permissions Enterprise subtechnique of · Technique T1505: Server Software Component Enterprise

Mitigations

Mitigation direction

M1047: Audit

Auditing is the process of recording activity and systematically reviewing and analyzing the activity and system configurations. The primary purpose of auditing is to detect anomalies and identify potential threats or weaknesses in the environment. Proper auditing configurations can also help to meet compliance requirements. The process of auditing encompasses regular analysis of user behaviors and system logs in support of proactive security measures.

Auditing is applicable to all systems used within an organization, from the front door of a building to accessing a file on a fileserver. It is considered more critical for regulated industries such as, healthcare, finance and government where compliance requirements demand stringent tracking of user and system activates.This mitigation can be implemented through the following measures:

System Audit:

- Use Case: Regularly assess system configurations to ensure compliance with organizational security policies. - Implementation: Use tools to scan for deviations from established benchmarks.

Permission Audits:

- Use Case: Review file and folder permissions to minimize the risk of unauthorized access or privilege escalation. - Implementation: Run access reviews to identify users or groups with excessive permissions.

Software Audits:

- Use Case: Identify outdated, unsupported, or insecure software that could serve as an attack vector. - Implementation: Use inventory and vulnerability scanning tools to detect outdated versions and recommend secure alternatives.

Configuration Audits:

- Use Case: Evaluate system and network configurations to ensure secure settings (e.g., disabled SMBv1, enabled MFA). - Implementation: Implement automated configuration scanning tools like SCAP (Security Content Automation Protocol) to identify non-compliant systems.

Network Audits:

- Use Case: Examine network traffic, firewall rules, and endpoint communications to identify unauthorized or insecure connections. - Implementation: Utilize tools such as Wireshark, or Zeek to monitor and log suspicious network behavior.

M1024: Restrict Registry Permissions

Restricting registry permissions involves configuring access control settings for sensitive registry keys and hives to ensure that only authorized users or processes can make modifications. By limiting access, organizations can prevent unauthorized changes that adversaries might use for persistence, privilege escalation, or defense evasion. This mitigation can be implemented through the following measures:

Review and Adjust Permissions on Critical Keys

- Regularly review permissions on keys such as `Run`, `RunOnce`, and `Services` to ensure only authorized users have write access. - Use tools like `icacls` or `PowerShell` to automate permission adjustments.

Enable Registry Auditing

- Enable auditing on sensitive keys to log access attempts. - Use Event Viewer or SIEM solutions to analyze logs and detect suspicious activity. - Example Audit Policy: `auditpol /set /subcategory:"Registry" /success:enable /failure:enable`

Protect Credential-Related Hives

- Limit access to hives like `SAM`,`SECURITY`, and `SYSTEM` to prevent credential dumping or other unauthorized access. - Use LSA Protection to add an additional security layer for credential storage.

Restrict Registry Editor Usage

- Use Group Policy to restrict access to regedit.exe for non-administrative users. - Block execution of registry editing tools on endpoints where they are unnecessary.

Deploy Baseline Configuration Tools

- Use tools like Microsoft Security Compliance Toolkit or CIS Benchmarks to apply and maintain secure registry configurations.

*Tools for Implementation*

Registry Permission Tools:

- Registry Editor (regedit): Built-in tool to manage registry permissions. - PowerShell: Automate permissions and manage keys. `Set-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run" -Name "KeyName" -Value "Value"` - icacls: Command-line tool to modify ACLs.

Monitoring Tools:

- Sysmon: Monitor and log registry events. - Event Viewer: View registry access logs.

Policy Management Tools:

- Group Policy Management Console (GPMC): Enforce registry permissions via GPOs. - Microsoft Endpoint Manager: Deploy configuration baselines for registry permissions.

Change history

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 .

ATT&CK release: 19.1
Object version: 1.0
Created: Mar 28, 2022, 15:34 UTC (UTC+00:00)
Modified: Oct 24, 2025, 17:48 UTC (UTC+00:00)
Raw hash: 8aa462d904601397...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	1.0	Oct 24, 2025, 17:48 UTC (UTC+00:00)	Current bundle	`8aa462d90460…`

Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

[1]
Microsoft Remote Desktop Services

Microsoft. (2019, August 23). About Remote Desktop Services. Retrieved March 28, 2022.
Open source URL
[2]
Microsoft System Services Fundamentals

Microsoft. (2018, February 17). Windows System Services Fundamentals. Retrieved March 28, 2022.
Open source URL
[3]
James TermServ DLL

James. (2019, July 14). @James_inthe_box. Retrieved September 12, 2024.
Open source URL
[4]
Windows OS Hub RDP

Windows OS Hub. (2021, November 10). How to Allow Multiple RDP Sessions in Windows 10 and 11?. Retrieved March 28, 2022.
Open source URL
[5]
RDPWrap Github

Stas'M Corp. (2014, October 22). RDP Wrapper Library by Stas'M. Retrieved March 28, 2022.
Open source URL
[6]
mitre-attack T1505.005
Open source URL

Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use