RD Web Access abuse: Fighting back

Since the start of 2024, the Sophos X-Ops Managed Detection and Response (MDR) team has responded to multiple incidents in which the initial access vector has been identified as an exposed Microsoft Remote Desktop Web Access portal lacking multi-factor authentication (MFA) protection. This article will provide an overview of what we have observed when this portal is abused, add insight into how we conduct these investigations, and give some recommendations and mitigating strategies to help anyone else that might be encountering (or simply anticipating) the same situation.

What is the RD Web Access portal?

The Microsoft Remote Desktop Services architecture is made up of multiple distinct roles, as shown in Figure 1.

Figure 1: Example of the roles installed on an exposed Remote Desktop Services (RDS) host

• The Remote Desktop Connection Broker (RD Connection Broker) role manages incoming remote desktop connections to RD Session Host server farms and routes connections to a suitable host.
• The Remote Desktop Gateway (RD Gateway) role is responsible for granting users on public networks access to Windows desktops and applications hosted within the RDS cluster. This role is often installed on the same host as the RD Web Access role, discussed below.
• The Remote Desktop Licensing (RD Licensing) role manages the user licenses and lets users connect to the RD Session Host servers hosting the virtual desktops or applications.
• Finally, the Remote Desktop Web Access (RD Web Access) login portal is the means by which users, and in these investigations threat actors, authenticate and ultimately reach the Remote Desktop Session Host (RD Session Host) – the goal in this stage. From the RD Session host, various sorts of activities can be launched, since the attacker has at that point achieved access inside your system. (In MITRE ATT&CK, this is T1133, Initial Access and External Remote Services.)

This article focuses on the RD Gateway, RD Web Access, and RD Session Host roles. For a broader look at how Remote Desktop Protocol (RDP) can be abused and how attackers do so, please see the RDP series we published earlier this year.

What happens when RD Web Access is abused?

When an RD Web Access host is exposed to the Internet, it allows users to login with their domain credentials to gain access to an RD Session Host, or to a virtualized application that allows them to work from anywhere and gain access to critical business resources. If these servers are not adequately protected while being exposed directly to the Internet, they can be abused by threat actors to gain access to an estate. The login portals are commonly brute-forced to gain legitimate user credentials, which are then used to login, create persistence, and attempt to escalate privileges or even move laterally within the estate.

Figure 2: Default login page for an RD Web Access portal

Upon successful authentication, the user will be presented with options to connect to a published RD Session Host or to a virtual application. If only presented with virtual applications, a malicious actor would need to “break out” of the contained application to execute code on the underlying host.

Figure 3: An RD Web portal presenting only a single published virtual application

The example in Figure 3 shows an RD Web portal with just one application, the Windows calculator, offered. Once the user selects the application, an .RDP file will be downloaded that will be pre-configured to launch the Calculator application. Since in this case there is no option to connect to a published RD Session Host, the goal for threat actors in this situation is to determine a way to execute code on the remote server that is hosting the calculator application.

One technique that has been observed by MDR leverages built-in Windows Accessibility functionality to gain access to a command prompt. When the Calculator application window has focus, the actor can press the shift key on their keyboard five times to bring up the Sticky Keys prompt. This prompt will be loaded from the remote RD Session host. Within the Sticky Keys prompt, there is an option to launch the accessibility options Control Panel item. This launches the Windows Control Panel, which in most cases will result in the classic Control Panel loading in a Windows Explorer window. From the Windows Explorer search bar, the actor can now simply type ‘cmd.exe’ and press enter to load an interactive command prompt on the RD Session host and begin action on their objectives.

If presented with the option to connect to an RD Session Host, the actor will be logged directly into an interactive Remote Desktop Session with a graphical user experience, from which they can further pursue their objectives. When a direct connection is established from the RD Web Access host to any of the session hosts, authentication logs will show an interactive RDP logon from the RD Web Access host, although it serves as a proxy for the connection from the actor’s machine to the RD Session host.

In four out of the five RD Web Access incidents MDR analyzed for this article, the MDR team responded to detections triggered in the discovery phase of the attack, when the threat actor(s) executed the command ‘nltest / domain_trusts’ to enumerate whether any Active Directory trusts existed on the targets. (The fifth case we analyzed likewise triggered on this behavior, but first fired on a different event, unique to that case.) Actors will often execute discovery commands to better understand the environment and underlying Active Directory domain infrastructure to which they’ve successfully gained access.

Figure 4: Examples of discovery commands following a successful connection

Upon investigation of these incidents, the MDR team observed consistent brute force attempts directed at the IIS process that serves the RD Web Access portal, eventually resulting in the threat actor gaining access.

Figure 5: Examples of brute force activity against the RDWebAccess IIS process

Throughout the triage phase of an incident response, the MDR team takes appropriate actions to disable any affected users and disconnect any active sessions to contain the threat as quickly as possible. If multiple accounts show signs of compromise, MDR will also isolate the RD Web Access host to ultimately stop any further access to the estate via that initial access vector. The MDR team makes use of numerous queries to assist with the investigation process and have included many of them in the following Investigative Guide section.

Investigative Guide

In this section, we provide a number of queries that investigators can use in cases where RD Web Access abuse is suspected. The queries in this section have been developed by the Sophos MDR team and can be run within the Sophos Central portal by navigating to Threat Analysis Center -> Live Discover. For readers not currently using Sophos Central, the general advice still holds, but the processes should be undertaken according to the technology you use.

Identifying exposed RD Web Access portals via OSINT

Often, a review of the external attack surfaces reveals numerous services that are exposed to the internet. The following Shodan search can identify exposed RDWeb servers.

hostname:<insert company domain name here> path=/RDWeb/

Identifying RD Gateway servers using Live Query

RD Gateway servers can be identified by the presence of the Remote Desktop Gateway service named ‘TSGateway.’ This is an endpoint query, so you will need to select all online servers within Sophos Central Live Discover to see which hosts have the RD Gateway role installed.

SELECT      name,      display_name,      start_type,      path,      status  FROM services  WHERE name = 'TSGateway'

Reviewing RD Gateway logs

Once it has been determined that a managed host is running the RD Gateway role, you can leverage the query below via Sophos Central Live Discover to obtain the most recent connection events from the RD Gateway Windows Event Logs. These logs will return the connection and disconnection events for the affected user and will reveal the remote source IP address responsible for connecting to the session. Once the source IP address has been determined, it is strongly recommended that you block it at your network perimeter. This is an endpoint query, so you will need to select only the hosts that were shown in the previous query (Identifying RD Gateway servers using Live Query) to be running the RD Gateway role.

SELECT  strftime('%Y-%m-%d %H:%M:%S',swe.datetime) AS Datetime,  swe.time,  swe.eventid AS EventID,  CASE   WHEN eventid = 200 THEN 'Client Connected'   WHEN eventid = 303 THEN 'Client Disconnected'  END AS Description,  JSON_EXTRACT(swe.data, '$.UserData.Username') AS Username,  JSON_EXTRACT(swe.data, '$.UserData.AuthType') AS AuthType,  JSON_EXTRACT(swe.data, '$.UserData.IpAddress') AS IpAddress,  JSON_EXTRACT(swe.data, '$.UserData.Resource') AS Resource,  JSON_EXTRACT(swe.data, '$.UserData.BytesReceived') AS BytesReceived,  JSON_EXTRACT(swe.data, '$.UserData.BytesTransfered') AS BytesTransfered,  JSON_EXTRACT(swe.data, '$.UserData.SessionDuration') AS SessionDuration,  JSON_EXTRACT(swe.data, '$.UserData.ConnectionProtocol') AS ConnectionProtocol  FROM sophos_windows_events as swe  WHERE source = 'Microsoft-Windows-TerminalServices-Gateway/Operational'  AND eventid IN (200,303)  AND swe.time > $$starttime$$  --AND swe.time > )$$starttime$$ AND swe.time < $$endtime$$  ORDER BY swe.time

Note the date/time-range information at the end of the query. This should be adjusted to suit the timeframe of the investigation. In the Sophos Central GUI, this can be selected using the date variable type; click on the calendar to select the start and end times.

Reviewing IIS logs

By default, IIS writes its logs in UTC and uses the format ‘YYYY-MM-DD hh:mm:ss.’ Minutes and seconds have been intentionally left out of the below grep pattern, so we capture a full hour of logs surrounding the login events. You will also need to update the ‘file.path’ value to reflect the date of the IIS log you want to review. The format for this is just YYMMDD (for example, 240223 for February 23, 2024).

Once you have run the previous query and know the timestamp for the successful logins from the RD Gateway event logs, you can modify the query below to obtain the surrounding IIS logs. This will give you data on the IIS login time, and on what the actor might have clicked on while connected to the web portal. As the source IP address is known from the results of the previous query, that information can also be used as a ‘grep.pattern’ filter to display all IIS logs containing that address. This is an endpoint query, so you will need to select the specific host within Sophos Central Live Discover.

SELECT grep.*  FROM file  CROSS JOIN grep ON (grep.path = file.path)  WHERE  file.path LIKE 'C:inetpubLogsLogFilesW3SVC%u_exYYMMDD.log'  AND grep.pattern = 'YYYY-MM-DD hh: '

Reviewing for signs of brute force activity

Brute force attempts towards an RD Web portal can be seen by filtering login events to the Windows IIS process, w3wp.exe, as seen in Figure 5 (above, previous section). This is a Sophos Central data lake query; as with the query for reviewing RD Gateway logs (above), time-range options for narrowing down the query can be set from the central GUI.

SELECT  meta_hostname, date_format(from_unixtime(CAST(event_timestamps AS bigint)), '%Y-%m-%d %H:%i:%S') AS event_timestamp, eventid, subject_username, subject_domain, target_username, target_domain, target_logon_id, subject_logon_id, logon_type, logon_process, authentication_package, transmitted_services, key_length, name, remote_address, remote_port, description, provider_name, source  FROM  xdr_data  WHERE  event_timestamps NOT LIKE '%,%'  AND   query_name IN ('windows_event_successful_logon','windows_event_invalid_logon')  AND name LIKE '%w3wp.exe%'  AND meta_hostname = '$$hostname$$'

 List RD Web-published applications via the Windows Registry

Review the Windows Registry to obtain a list of published applications or session hosts, along with any permission restrictions that may be in place for those listed items. This is an endpoint query, so you’ll need to select the specific host within Sophos Central Live Discover.

SELECT path, data, type, strftime('%Y-%m-%d %H:%M:%S',datetime(mtime,'unixepoch')) AS modified_time  FROM registry  WHERE path LIKE 'HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal Server%%'

Reviewing compromised account history across the estate

Once a compromised account is identified as logging in through the RD Web portal, the following query can be used to investigate the user activity. This helps you to discover if the threat actor has moved to other hosts within the network based on the results. This is a Sophos Central data lake query. Note that you will need to provide the full username on the second-to-last line of the query.

SELECT   meta_hostname,   date_format(from_unixtime(time), '%Y-%m-%d %H:%i:%s') as date_time,   username, cmdline, name, path, sophos_pid, parent_name,parent_cmdline,parent_path, parent_sophos_pid, uid, gid,file_size, sha1, sha256   FROM   xdr_ext_data   WHERE   query_name = 'running_processes_windows_sophos'   AND username = '$$username$$'   ORDER BY date_time DESC

Gathering information about the compromised account

The following Sophos Central data lake query can be used to get more information on the compromised account.

SELECT  meta_hostname,uid, gid, username, description, directory, shell, type, uuid  FROM  xdr_data  WHERE  query_name = 'user_accounts'  AND username = ‘$$username$$’

In conjunction with the above query, these PowerShell commands can be used to examine a domain or local user in order to obtain more user account properties like last password change, account enabled, and such. As with the previous query, note that you will need to provide the full username on the second-to-last line of the query.

MDR Response Actions

Incidents involving an exposed RD Web Access host require prompt action be taken to neutralize the threat before any lateral movement takes place. As such, our MDR team commonly performs the following response actions to move compromised systems to a contained state as quickly as possible.

• Isolate impacted hosts, including the RD Gateway, to stop further authentication attempts against the exposed login portal
• Note and block the source IP address that was used to illegitimately log into the portal
• Disable impacted domain users
• Block malicious executable hashes in Sophos Central
• Implement Application Control policies within Sophos Central to restrict the execution of commonly abused tools
• Submit malicious and unknown files to SophosLabs to be classified and have new detections created

Recommendations and Mitigation Strategies

While RD Web Access is useful as a means for users to connect to business resources from remote locations, there are some critical recommendations that should be implemented to reduce the attack surface of the exposed systems. The following three actions, taken prior to an attack, may mitigate attack efficacy:

• Implement multi-factor authentication and ensure it is being enforced for all domain users
• Review the configuration of the published applications and RD Session hosts to ensure that only expected and approved items have been published, and to only the users that are expected to have access to them. Consider creating a group policy object to deny access to cmd.exe and PowerShell for any users that don’t require it.
• If possible, restrict Internet access to the login portal to only approved source IP addresses

If the above recommendations and mitigation strategies cannot be implemented and you must continue to use an RDS cluster, consider protecting the RD Web Access portal behind a VPN, with MFA enabled and enforced. This keeps the portal from direct exposure to the internet and thus reduces the attack surface of the exposed application.

Conclusion

Analysis of the current popularity of RD Web Access abuse, or which threat actor(s) might be choosing this technique, is beyond the scope of this article. We do however note that unprotected internet-facing Remote Desktop access is a known-bad choice, as is the lack of MFA on the systems we saw. Articles such as this one are not an effort to shame the victims of attacks; rather, we hope to provide insight into how to investigate such incursions, while encouraging readers to follow best security practices and, perhaps, avoid ending up in this situation.