Ransomware Groups Use Tor-Based Backdoor for Persistent Access

In 2020 and 2021, Secureworks® Counter Threat Unit™ (CTU) researchers observed several threat groups using the official Tor client to create a backdoor with persistent access to compromised networks via Remote Desktop Protocol (RDP). Third-party researchers documented similar activity during a mid-2018 intrusion. The Tor client can be used to create a local SOCKS proxy that allows proxy-aware applications to access the Tor network. Tor can also create Onion Services (originally known as hidden services) that can then be accessed through the Tor network. The threat actors create an Onion Service that allows a remote attacker to connect to the RDP service on the compromised host.

By default, Tor stores metadata used to maintain a connection to the Tor network in the %APPDATA%\tor directory. The location of this directory can be changed by modifying the DataDirectory directive in the configuration file. An alternative path to a configuration file can be provided to the Tor client at runtime with the -f command-line parameter. The folder's creation time is the moment Tor was first executed by the user. Within this directory, the "lock" file's modification timestamp matches the time the Tor client was last executed. Tor periodically updates the "state" file; its modification timestamp can vary up to a few minutes from the Tor client's last activity.

While running, the Tor client maintains an open session with the Tor network that brokers inbound connections to the Onion Service. When a remote attacker connects to the onion address and port pair registered as the Onion Service, the connection is redirected to the IP address and port specified in the HiddenServicePort configuration directive. When the HiddenServicePort directive is configured as the loopback IP address (127.0.0.1), the connection is redirected to the localhost.

Beginning in mid-2020, CTU™ researchers analyzed several incidents where threat actors leveraged an Onion Service on a compromised system to redirect inbound requests to the local RDP service. The financially motivated GOLD WATERFALL threat group perpetrated two of these incidents, one of which included deployment of the Darkside ransomware. The threat actors installed Tor into the C:\Windows\Inf\Usb folder and executed it via the following command line:

C:\Windows\Inf\Usb\Tor\tor.exe -f C:\Windows\Inf\Usb\config.dat

To maintain the Tor client's persistence, GOLD WATERFALL used the Non-Sucking Service Manager (nssm.exe) to install Tor as a service. Figure 1 shows the Tor configuration.

CTU researchers discovered another victim that had a domain controller containing an identical setup installed during or before April 2020. This victim's network was not infected with ransomware. It is unclear if GOLD WATERFALL had access to this host, but at the time the group was a REvil ransomware affiliate.

In a separate incident observed in February 2021, a threat actor distributing the Snatch ransomware set up a Tor backdoor using the configuration in Figure 2. The configuration file and other tactics, techniques, and procedures (TTPs) match details in a June 2020 third-party report on Snatch ransomware activity.

To keep the Tor client running, the threat actors executed a service.bat Windows batch script to create a service using the Service Control (sc.exe) command-line utility (see Figure 3).

Although the threat actors used these backdoors in all of the analyzed intrusions, it is possible that the backdoors were created by initial access brokers (IABs) who compromised the victims' networks. The IABs sell the credentials, a summary of the victim's environment (number of endpoints, etc.), and the onion address hosted within the network.

The Windows event log writes the following three events when a threat actor successfully authenticates via RDP exposed using this type of Tor backdoor. The data in the figures is contrived for demonstration purposes.

• Event 4624 Logon Type 3 (network) is written to the Security log. The account name is the user whose credentials are compromised, and the workstation name is the computer name used by the attacker (see Figure 4).
  
  Figure 4. Windows event 4624 indicates a successful logon. (Source: Secureworks)


• Event 1149 is written to the Terminal Services Remote Connection Manager log. The expected source network address is the remote IP address of the connecting user, but this activity uses loopback address 127.0.0.1 (see Figure 5).
  
  Figure 5. Windows event 1149 indicates successful RDP authentication. (Source: Secureworks)


• Event 25 is written to the Terminal Services Local Session Manager log. This event also contains the anomalous loopback address in the source network address field (see Figure 6).
  
  Figure 6. Windows event 25 indicates successful RDP session reconnection. (Source: Secureworks)

Tor is designed to operate within adversarial environments where governments or other well-resourced entities attempt to deny or monitor internet communication. Blocking published Tor entry nodes at network egress points may be effective against Tor clients that use the default protocol. Tor clients that use bridges and pluggable transports are much more difficult to block because the infrastructure is more dynamic and cannot be compiled into easily consumed lists. Intrusion prevention systems (IPS) are often capable of performing the deep packet inspection necessary to identify obfuscated Tor traffic.

To mitigate exposure to this threat, CTU researchers recommend that organizations use available controls to review and possibly restrict access using the indicators in Table 1. Additional information about the GOLD WATERFALL threat group that operates the Darkside ransomware is available in the public threat profile.