Researchers Use Microsoft Terminal Services Client in New Attack Method
The technique would enable attackers to run malicious code via Remote Desktop Protocol using DLL side-loading to bypass security controls.
Researchers have discovered a defense evasion technique that could allow attackers to run malicious code through the Microsoft Remote Desktop Protocol (RDP) using an attack tactic called DLL side-loading. The method leverages Microsoft Terminal Services Client (MSTSC).
Cymulate team members were researching MSTSC and RDP when they discovered the technique, which can be used to bypass security controls, CTO Avihai Ben-Yossef writes in an email to Dark Reading. As far as the researchers know, this strategy has not been used in active attacks.
DLL side-loading, as it's labeled in the MITRE ATT&CK framework, can happen when programs "improperly or vaguely specify a required DLL." As a result, they may be open to a vulnerability in which an unintended DLL is loaded into the program. Attackers can take advantage of legitimate programs vulnerable to side-loading to load a malicious DLL and mask any malicious actions they take under the guise of a trusted system or process.
To run RDP, users access the MSTSC in Windows to take control of a remote computer or virtual machine using a network connection, the researchers explain in a blog post. MSTSC relies on a DLL file (mstscax.dll) as one of its resources. Researchers learned MSTSC performs delay-loading of mstscax.dll with a behavior that can lead to attackers slipping past security controls. The executable loads "mstscax.dll" with no integrity checks to validate the library's code, they say.
There are two ways to exploit this, Ben-Yossef explains. An attacker could replace the DLL mstscax.dll in the folder c:\windows\system32, which requires local administrative privileges. "Most attackers are gaining local administrative privileges in various techniques and therefore will be able to exploit this for post-exploitation and evasion usage," he continues.
In another scenario, an attacker could copy mstsc.exe to an external folder, placing the DLL in the same folder and running mstsc from there. This does not require admin privileges, Ben-Yossef notes. Microsoft says the mstsc should not be used outside the folder c:\windows\system32; however, this is not enforced, Ben-Yossef says.
Both scenarios let an attacker bypass security controls because malicious code runs under the context of mstsc.exe, which is a Microsoft-signed executable. The first scenario will allow attackers to persist, he adds, because mstsc.exe will run the malicious code every time it's used.
"Attackers can take advantage of the fact that most security controls are not securing mstsc.exe as it is a widespread software signed by Microsoft," Ben-Yossef explains. "So if a malicious code runs under its context, it has high chance of not being detected."
Cymulate contacted Microsoft to share its findings on April 12, and the company declined to develop a patch. Compromising the Remote Desktop client by planting DLLs in a trusted directory would require an attacker to have administrator privileges, Microsoft explains. The company offers additional guidance on how DLL planting vulnerabilities are handled. Based on where the malicious DLL can be planted, the vulnerability may fall into different categories.
Organizations that want to mitigate this threat can disable the use of mstsc.exe, use security controls to monitor malicious abnormal behavior being executed by mstsc.exe, and manually validate that the DLL mstscax.dll in the same folder as the real DLL signed by Microsoft, and not a fake one, Ben-Yossef says.
Related Content:
Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's featured story: "How Can I Help My Users Spot Disinformation?"
About the Author
You May Also Like
DevSecOps/AWS
Oct 17, 2024Social Engineering: New Tricks, New Threats, New Defenses
Oct 23, 202410 Emerging Vulnerabilities Every Enterprise Should Know
Oct 30, 2024Simplify Data Security with Automation
Oct 31, 2024Unleashing AI to Assess Cyber Security Risk
Nov 12, 2024