SparkRAT: Exploiting Architectural Weaknesses in Open-Source Offensive Tools

Introduction

SparkRAT is an open-source, freely available, and widely used Remote Access Trojan and C2 server, all of which led us to want to explore it further. In this article, we look at the global use of open-source malware, compare the threat actors and nation states that use closed and open-source tooling in their activities, and dig into the specifics of SparkRAT itself, including vulnerabilities and architectural flaws in it that we discovered in the course of our research.

We’ll finish things off with a reliable YARA rule to detect SparkRAT in your environment.

The Rise of Offensive Open-Source Tooling

The U.S. Cybersecurity and Infrastructure Security Agency’s 2020 advisory—plainly titled “Publicly Available Tools Seen in Cyber Incidents Worldwide”—removed any lingering doubt that open-source offensive tooling is a marginal issue.¹ The agency’s assessment, reinforced by a growing body of incident-response reporting, indicates that freely available offensive tooling now forms a routine part of intrusion tradecraft. Formal data supporting this is in short supply. However, trend data is available for 2015 through to 2020 showing a clear growth trend in the adoption of offensive tools for which the source code is widely available.²

Observationally, strategic preferences appear to diverge by geography: Five Eyes intelligence services tend to favor bespoke, high stealth capabilities that minimize disclosure risk, whereas several East Asian threat groups appear to bias toward breath and volume of intelligence.

From the attacker’s perspective, the economic incentives of open-source offensive tools are compelling. Fully featured remote-access Trojans (RATs) and turnkey C2 servers can be lightly customized, assembled for operational use, and deployed at negligible cost.^1, 2, 3 The use of freely accessible offensive tooling muddies attribution and increases deniability.^4, 5

The upsides for East Asian threat groups are significant but are far from being risk free. We believe there are theoretical, and in many cases practical downsides that are under-leveraged by defenders. Defenders can acquire the very same source code, and blue- or purple-teams can emulate adversary behavior to benchmark and improve on detections and response procedures.⁶ As with all freely available source code, the potential for supply-chain vulnerabilities and deliberate backdoors exist, although the only documented examples of this have been campaigns targeting less sophisticated operators, and therefore outside of the scope of consideration of this article.⁷ Perhaps the most pernicious downside for attackers is that significant customization of open-source offensive tooling creates the intuitively increased risk of attribution, if the customized version is used more than once, whilst also undermining the economic benefits.

Timeline of SparkRAT in the Wild

F5 Labs assesses SparkRAT to be a relatively sophisticated open-source remote-access Trojan (RAT) that offers attackers a low-cost option, with architecture-native builds produced out-of-the-box for Windows, Linux, and macOS. All the desirable RAT features are present, with the perhaps notable absence of Remote Desktop-like functionality. These factors have combined to make SparkRAT an attractive offensive tool choice, as is evidenced by the documented instances of its use in threat campaigns.

Publicly available reporting begins on 2023-01 and has carried through to the present. This demonstrates the steady broadening in both the geographic spread and adversary diversity of SparkRAT deployments. Use of SparkRAT started out with East Asian ties of varying strength and over time has expanded, even being used in the Russia-Ukraine war.

• 2023-01 Chinese speaking threat actors deployed DragonSpark to target East Asian organizations⁸
• 2023-03 SparkRAT C2 servers hosted in infrastructure linked to Winnti (APT41, China)⁹
• 2023-06 Multiple attacks detected in China by Patchwork APT (aka Monsoon with ties to India)¹⁰
• 2023-05 SparkRAT used in targeting of Korean VPN Installers popular in China^11, 12
• 2024-07 SparkRAT used by a TAG-100 (aka Storm-2077 linked to China¹³) targeting high-profile government, intergovernmental, and private sector organizations globally¹⁴
• 2024-03 SparkRAT used in the wild by unknown actors using LESLIELOADER (with very tenuous ties to China¹⁵)¹⁶
• 2024-11 SparkRAT used to target Ukrainian organizations (suspected to be UAC-0194 with Russian links)¹⁷
• 2024-12 SparkRAT used by Cyber Anarchy Squad to target Russian and Belarusian organizations¹⁸
• 2025-01 SparkRAT detected in use by unknown actors¹⁹

Getting to Know SparkRAT

As a quick refresher, a Remote Access Trojan (RAT) is malicious software engineered to grant an attacker control over a compromised endpoint. Once running, a RAT will establish communications with command & control infrastructure (C2) and await instructions from an operator. SparkRAT at a high-level follows this model exactly.

Communication is primarily over WebSockets using HTTPS. SparkRAT’s own documentation succinctly outlines available functionality and cross-platform support.

SparkRAT Architecture and Inherent Weaknesses

The development of any tool inherently encapsulates its own distinct design choices that each bring with them implicit trade-offs. Through the lens of security this takes the shape of outright security vulnerabilities and subtler architectural weaknesses. SparkRAT is no different in this respect. The following are significant design choices and their associated architectural weaknesses which amount to a significant attack surface potential for defenders:

Program Language Choice

• Written in Go, ensuring friction-less cross-platform builds; the flip side is that the characteristic Go runtime artefacts make static detections more straightforward.

Config

• Embeds its full client configuration inside the executable, defeating simplistic hash-based detections while simultaneously handing defenders a consistent location from which to extract that configuration.
• Credentials are shipped inside the embedded configuration, which is convenient simplicity but eases interactions with the C2 for defenders.

C2 Communication

• The C2 server exposes a conventional HTTPS endpoint, blending into normal web traffic protocols yet offering defenders well-understood inspection surfaces.
• Operators can specify non-default ports and URL paths, reducing the effectiveness of scanning for C2 infrastructure but creating potentially identifiable patterns for attribution in the process.
• The client does not implement certificate pinning, so person-in-the-middle solutions allow for inspection and/or blocking.
• Initial authentication and session establishment take place over persistent WebSocket channels providing a session secret that can be used by defenders out-of-band of the WebSocket with the C2 REST API.
• All operator commands are relayed by the C2 server over WebSockets directly from the operator UI through to the client. This opens up the potential for defenders to exploit this trust relationship and potentially compromise the operator’s browser.
• WebSocket traffic is still comparatively rare in many corporate networks; defenders who alert on atypical protocol use may identify SparkRAT purely on this basis – potentially even based purely on encrypted network traffic patterns.
• The operator UI API endpoints and client API endpoints are exposed over the same HTTP port, creating the possibility for defenders to pivot from client configuration to enumerating the operator API.
• All of the C2 server API endpoints follow REST conventions, aiding defenders in any enumeration of the API attack surface.
• By default, the operator UI requires no authentication, an insecure setting that invites accidental exposure or deliberate takeover.

Client Updates

• The client and server support updating the client to newer versions, which introduces the potential for defenders to turn compromise of the C2 into inoculating the infected hosts. While this is a downside, it is unavoidable, inherent in the feature set of RATs due to the control they provide operators.
• Update retrieval is handled via separate REST requests, enlarging the attack surface and providing defenders with an additional telemetry point. F5 Labs wrote up detection of such defensive scanning behavior in Delving Into the SparkRAT Remote Access Tool.
• Update versions are referenced by Git commit SHA values, unintentionally revealing development lineage and aiding threat hunting.
• Updating a client version on the server-side injects the client configuration into newly built binaries, providing defenders who have access to the C2 server with a means to update their defensive signatures as new versions are published.

Exploiting SparkRAT Weaknesses

The aforementioned architectural weaknesses are not purely theoretical. On their own or combined with security vulnerabilities they can lead to compromise of attacker infrastructure. This section is a somewhat circumspect case study of exploiting a SparkRAT C2 in the wild. It is plausible enough that vulnerabilities exploited by F5 Labs are known to defenders and unknown to attackers. Therefor this section attempts to strike the balance between being informative for defenders without revealing too much to attackers. We did not want to provide a pentest report that could be used directly as a hardening guide for threat actors using SparkRAT.

It should be made clear to readers that there is nothing particularly unusual or novel about the exploitation in this SparkRAT C2. If anything, the SparkRAT code quality is significantly superior to code bases in common use. AppSec is difficult. It is very common to fall short of robust code security ideals. If anything, this section serves as a warning to attackers that they should expect most all code to have latent exploit potential. Similarly, it appears very reasonable to us to suggest to defenders that F5 Lab's experience with SparkRAT will generalize well to other similar open-source tools.

Our “defend forward” story begins with the discovery of client configuration for accessing a SparkRAT C2 in the wild. As a reminder, SparkRAT clients embed their configuration within the binary, and while the configuration is obfuscated the client binary necessarily has the means to obtain the plain text JSON for its configuration.

With the valid client configuration and the confirmed availability of its associated C2, F5 Labs was in a position to be able to make a custom version of the SparkRAT client in order to safely interact with the C2. This is the first significant advantage widely available source code presents the defender: it enables not only analysis of the client and server code but also customization. F5 Labs customized the SparkRAT client to disable all RAT functionality while retaining all functionality for communication with the C2 server.

With a safe-to-use SparkRAT client, F5 Labs was able to enumerate the SparkRAT C2 attack surface. This, in conjunction with analysis of the server code allowed F5 Labs to successful develop an exploit chain. We won't be revealing the nature of this particular exploit chain, suffice to say that we limited our use to a bare minimum; Just enough to prove the capability and perform some basic reconnaissance of the C2 host. Organizations or agencies with a wider remit for their operations could do a lot more here than we were willing to.

The C2 server used a non-standard port and required a URL path prefix. There were no newer versions of the client than the binary we had access to. Architecture support was for the out-of-the-box variants. No other SparkRAT clients were actively connected. The C2 server was running in Oracle Cloud Infrastructure (OCI) Compute (readers can consider OCI Compute analogous to Amazon EC2). The only valid user for the host was root. Root had no password set, had no ssh setup for remote access in or out of the host, and appeared to have never logged in to the host (according to the various shell histories). A source familiar with the workings of OCI Compute clarified the lack of access by root, stating: “Oracle Cloud instance agent can run commands via the API if enabled … [it has] a policy permission to invoke commands”. The C2 server is currently offline at the time of writing.

Indicators of Compromise

Hash IoCs for SparkRAT are of limited use. This is because client configuration is embedded in the SparkRAT binary, and a threat actor can generate binaries with unique hashes as a matter of course via the C2 API. YARA rules however are of use as even stripped Go binaries contain rich information about the original naming of the source code.

F5 Labs has developed a set of YARA rules for detecting the SparkRAT client, which is available from our public GitHub repository https://github.com/F5-Labs/SparkRAT-YARA-rules.

Commonly available SparkRAT YARA rules look for strings like "Spark/client/config.GetBaseURL". However, anyone familiar with Go will know that at a minimum the prefix “Spark/client” is easily modified, and with increasing mechanical minutae both “config” and “GetBaseURL” can be renamed also using software engineering refactoring tools. Our intention is to have a minimal false positive rate and to match on variants of SparkRAT that can have added functionality or have renamed portions of the codebase to evade detections.

The first SparkRAT rule will match SparkRAT binaries by looking for IoCs of vanilla SparkRAT builds in which the threat actor has made efforts to obscure Go build artifacts.

The second rule has match criteria which look for the use of ~90% of the dependencies used by SparkRAT (with a cap on the actual number of dependencies to limit false positives).

The third rule matches if ~50% of the original SparkRAT methods are present.

Finally, an overall rule ties the rules together along with a basic check for file size. All told, these criteria increase the chances of detecting SparkRAT variants that have not undergone determined efforts to obscure the original source code.

F5 Labs has verified this rule generated no false positives against of four years of malware samples from Malware Bazaar (2020-02 through 2024-04). In total, 29 malware samples matched the F5 Labs YARA rule and represented at least seven distinct variants – readers will recall from earlier that unique hashes of the entire binary do not necessarily imply unique SparkRAT variants as client configuration is embedded within the binary.
 

Conclusion

As F5 Labs noted in previous reporting in Delving Into the SparkRAT Remote Access Tool, subjectively speaking, the SparkRAT code is exemplary for open-source. The code is clean, well-written, appropriately complex, and architecturally elegant.

Nevertheless, there are some architectural flaws, and even some vulnerabilities, which should tell you that there’s no such thing as perfect code – and perhaps lead you to your own investigations of open-source malware with an eye towards finding and perhaps leveraging these flaws to enhance your defenses.