Home/ATT&CK Technique/Terminal Services DLL
ATT&CK Technique

Terminal Services DLL

T1505.005 · persistence

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.

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. 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.

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. 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.

Windows
▸

Atomic Tests

2
Executable Atomic Red Team test cases for exercising this technique in a lab. Copy a command, run it on the listed platform, confirm your detections fire.
powershellelevatedwindowsSimulate Patching termsrv.dll
Simulates patching of termsrv.dll by making a benign change to the file and replacing it with the original afterwards. Before we can make the modifications we need to take ownership of the file and grant ourselves the necessary permissions. 
$termsrvDll = "C:\Windows\System32\termsrv.dll"

$ACL = Get-Acl $termsrvDll
$permission = "Administrators","FullControl","Allow"
$accessRule = New-Object System.Security.AccessControl.FileSystemAccessRule $permission
$ACL.SetAccessRule($accessRule)
Set-Acl -Path $termsrvDll -AclObject $ACL

Copy-Item -Path "C:\Windows\System32\termsrv.dll" -Destination "C:\Windows\System32\termsrv_backup.dll" -ErrorAction Ignore
Add-Content -Path "C:\Windows\System32\termsrv.dll" -Value "`n" -NoNewline -ErrorAction Ignore
Move-Item -Path "C:\Windows\System32\termsrv_backup.dll" -Destination "C:\Windows\System32\termsrv.dll" -Force -ErrorAction Ignore
powershellelevatedwindowsModify Terminal Services DLL Path
This atomic test simulates the modification of the ServiceDll value in HKLM\System\CurrentControlSet\services\TermService\Parameters. This technique may be leveraged by adversaries to establish persistence by loading a patched version of the DLL containing malicious code.
$termsrvDll = "C:\Windows\System32\termsrv.dll"

$ACL = Get-Acl $termsrvDll
$permission = "Administrators","FullControl","Allow"
$accessRule = New-Object System.Security.AccessControl.FileSystemAccessRule $permission
$ACL.SetAccessRule($accessRule)
Set-Acl -Path $termsrvDll -AclObject $ACL

Copy-Item -Path $termsrvDll -Destination "$HOME\AtomicTest.dll"

$newServiceDll = "$HOME\AtomicTest.dll"

$registryPath = "HKLM:\System\CurrentControlSet\services\TermService\Parameters"

# Check if the registry key exists
if (Test-Path -Path $registryPath) {
    # Modify the ServiceDll value in the registry
    Set-ItemProperty -Path $registryPath -Name "ServiceDll" -Value $newServiceDll
    Write-Host "ServiceDll value in the registry has been updated to: $newServiceDll"
} else {
    Write-Host "Registry key not found. Make sure the 'TermService\Parameters' key exists."
}
▣

Mitigations

2
MITRE ATT&CK mitigations - vendor-agnostic guidance for reducing exposure to this technique.
M1024Restrict 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.

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.
M1047Audit

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.

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.
◈

Detection Coverage

1/6 layers
Coverage across standard detection surfaces. Rows marked none have no rule of that type mapped. Some are real blind spots worth closing; others are simply not applicable to this technique (e.g. YARA matches malware files, not network behaviour).
Behavioral / log (Sigma) 1
Analytics (MITRE CAR) none
Runtime / container (Falco) none
File / malware (YARA) none
Network (Suricata/Snort) none
Vuln scan (Nuclei) none
▣

Comply & Defend

NIST 800-53AC-02, AC-03, AC-05, AC-06, AC-12, AC-17, AC-20, CM-02, CM-06, RA-05, SI-04
Intelligence Graph · click any node to traverse
CVETechnique ActorTool Family
drag to reposition · click any node to traverse · button top-right enlarges
External lookups - second-class, for what we don’t hold ourselves
MITRE ATT&CKAtomic Red Teamcar (MITRE)
Vulnerabilities
CISA KEV catalog
CWE weaknesses
CAPEC attack patterns
Package vulnerabilities
Threat intelligence
Threat actors
Tools & malware
ATT&CK techniques
IOCs
Detection & defense
Sigma rules
YARA rules
Atomic Red Team tests
D3FEND countermeasures
Compliance
NIST 800-53
ISO 27001:2022
SOC 2 TSC
PCI-DSS v4.0
CIS Controls v8.1
About
All capabilities
Live statistics
Data sources
Privacy policy
Terms of service
threatengine.sh  ·  Open-source threat intelligence platform  ·  100+ authoritative sources  ·  Every fact traces to its origin