Back in May of this year, cyber Security company BitDefender released a paper detailing research work they have undertaken which looks at a new exploit which takes control of sessions using the Remote Desktop Protocol (RDP) to infect victims with a backdoor allowing for data to be exfiltrated.
The exploit is known as RDStealer and when deployed against a potential victim, listens for RDP sessions to be established and then infects connecting clients with a backdoor known as Logutil which opens the way for the data exfiltration.
In their examination of a compromised device, they identify that the malicious activity was targeting a company operating in the IT services/Tech verticals in East Asia, but there is nothing to suggest that the victims will always be in East Asia.
How it works
A compromised machine is scanned for interesting data to be exfiltrated and at the same time is scanned for the signs of existing RDP sessions.
Often, when two devices are connected via RDP, a feature called Client Drive Mapping (CDM) is used to facilitate the transfer of files between the devices. CDM utilises a Windows function called DiskMounted to connect to remote drives.
RDStealer constantly scans an infected device for the DiskMounted function, indicating an RDP connection is available.
If DiskMounted is detected and a shared drive is identified, then the malware instigates a number of actions:
- main.notifyMaster – Notify command & control (C2) server that a client is connected.
- Main.DiskEnum – Start exfiltrating data from the connected RDP client.
- main.writePersist – Deploy Logutil backdoor to the connected RDP client.
DLL sideloading
The Logutil backdoor utilises a process known as DLL Sideloading to infect an RDP connected device.
A DLL (Dynamic Link Library) is a special file on a Windows machine which provides functionality for applications to save developers from having to code those functions themselves. When building an application, all a developer needs to do is write code that fetches a specific function from a DLL provided by the Windows operating system and then the application will have that function.
DLLs are loaded into memory by the operating system and the application fetches the function from the specified memory address.
On a Windows device, the DLLs are stored in certain, known locations (e.g. \windows\system32)
DLL sideloading is a technique which takes advantage of a quirk in how Windows deals with legacy DLLs which some applications may require to function properly.
If a application developer writes code that depends on an outdated version of a DLL and deploys it to a shared location, such as \Windows\System32 it might get overwritten by a newer version of the DLL with a windows update, thus causing issues for the application.
A simple fix for this issue is to copy the legacy DLL into the same folder as the application executable so that when the application searches for the required DLL, it finds it in its own folder and as such loads the older version of the DLL, while all other applications use the latest version from the shared location.
DLL sideloading abuses the process of putting DLLs in different locations. Threat actors re-write older DLLs with malicious versions. This malicious DLL uses the filename that the target application is known to request.
After the initial binary is launched, it locates and sideloads the malicious library located in the same folder. This attack vector is based on a design flaw in the way that Windows OS locates libraries and vendors whose software is abused can’t do anything to prevent these attacks.
DRStealer compromises a victim machine by sideloading a a malicious version of the ncobjapi.dll file to obtain persistance on the remote RDP device.
